LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 12-02-2008, 10:13 AM   #1
irey
Member
 
Registered: Jun 2008
Location: Torino, Italy
Posts: 65

Rep: Reputation: 17
can 127.0.0.1 be spoofed ?


Hi,

I've been searching the web on this argument but all it talks about is UDP. I have no doubt that a UDP packet can have a fake localhost source address. But what happens with TCP? I think a SYN packet can arrive with a fake localhost source address, but then the SYN ACK will be sent to localhost and never received by the attacker. Am I right?

If I write a servlet that checks wether the remote address is 127.0.0.1, would it be vulnerable?
 
Old 12-02-2008, 11:49 AM   #2
rahulk
Member
 
Registered: Mar 2006
Posts: 110

Rep: Reputation: 16
Quote:
Originally Posted by irey View Post
Hi,

I've been searching the web on this argument but all it talks about is UDP. I have no doubt that a UDP packet can have a fake localhost source address. But what happens with TCP? I think a SYN packet can arrive with a fake localhost source address, but then the SYN ACK will be sent to localhost and never received by the attacker. Am I right?

If I write a servlet that checks wether the remote address is 127.0.0.1, would it be vulnerable?
The ARP table for Linux does not have the lo interface entry and hence it will not allow you to spoof the entry for "lo" interface (lo is the internal loopback interface, which is virtual).

Rahul Khare.
 
Old 12-02-2008, 11:56 AM   #3
irey
Member
 
Registered: Jun 2008
Location: Torino, Italy
Posts: 65

Original Poster
Rep: Reputation: 17
You're right about the ARP table observation, but IP spoofing can be done even without ARP poisoning.
 
Old 12-02-2008, 12:13 PM   #4
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Well, I can tell you this much at least: If I spoof a SYN packet with source IP 127.0.0.1 sending it from my laptop to my desktop via Wi-Fi, I can see the packet arrive at my desktop (using tcpdump). I can NOT, however, log the packet with Netfilter/iptables on the desktop for some reason. EDIT: I'll check if I can see the any ACK get generated on the desktop when I get back, gotta go out to take care of something. Will be back later today.

Last edited by win32sux; 12-02-2008 at 12:15 PM.
 
Old 12-02-2008, 05:33 PM   #5
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Okay I was able to look at this a bit more. I don't really have much new information to share, though. I can confirm that the spoofed packet (source address 127.0.0.1) isn't causing a SYN/ACK to be generated on the target machine. I checked the NIC and loopback on the target using tcpdump. The spoofed packet is clearly visible to tcpdump on the target machine, yet it doesn't show-up in the iptables logs. Can anyone shed some light as to what is happening to the spoofed packet? Why doesn't it reach Netfilter? Why doesn't it generate a SYN/ACK?

FWIW, the target machine I tested with is running Linux 2.6.22.

Quote:
Originally Posted by irey View Post
then the SYN ACK will be sent to localhost [...] Am I right?
I don't have the complete picture yet, but (as you can see above) my tests show the answer to this question is: NO.

Last edited by win32sux; 12-02-2008 at 05:48 PM.
 
Old 12-03-2008, 03:00 AM   #6
irey
Member
 
Registered: Jun 2008
Location: Torino, Italy
Posts: 65

Original Poster
Rep: Reputation: 17
I'm not surprised. It appears that the IP layer is smart enough to realise that the packet is spoofed since obviously the localhost address shouldn't be received on eth0 or any interface other than lo. Maybe tcpdump is working on the ethernet layer so it sees the packet before it is discarded.

Anyway your reply shows that it is secure. If the SYN ACK hasn't been generated then the connection hasn't beene stablished and any following packets will be discarded.

I was fearing that a potential attacker could send the SYN, ignore the never-received-SYN-ACK and finally send an ACK and a HTTP request. Since the connection hasn't been established, his attack won't work.

I don't know how you tested it, but I don't want to learn. Thanks for your reply.
 
Old 12-03-2008, 03:42 AM   #7
irey
Member
 
Registered: Jun 2008
Location: Torino, Italy
Posts: 65

Original Poster
Rep: Reputation: 17
Some internet searching showed me that your test fake packet was detected by the "reverse path filtering", a kernel feature that drops packets received on a wrong interface. It may be configured through some sysctl variables:

net.ipv4.conf.default.rp_filter
net.ipv4.conf.all.rp_filter

Maybe that's the light you were asking for .
 
Old 12-03-2008, 11:51 AM   #8
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by irey View Post
Some internet searching showed me that your test fake packet was detected by the "reverse path filtering", a kernel feature that drops packets received on a wrong interface. It may be configured through some sysctl variables:

net.ipv4.conf.default.rp_filter
net.ipv4.conf.all.rp_filter

Maybe that's the light you were asking for .
Actually, I made sure rp_filter was disabled before doing my test. I was thinking I'd activate it if the test failed.

BTW, I think I might as well post the tcpdump output (from the target machine) of my test.

Throwing a single SYN packet at a Squid daemon:

Using real source:
Code:
12:43:30.818075 IP (tos 0x0, ttl 64, id 51213, offset 0, flags [none], proto TCP (6), length 40) 192.168.1.100.2186 > 192.168.1.101.3128: S, cksum 0x3f3f (correct), 1779957662:1779957662(0) win 512
12:43:30.818634 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44) 192.168.1.101.3128 > 192.168.1.100.2186: S, cksum 0x58da (correct), 3277349504:3277349504(0) ack 1779957663 win 5840 <mss 1460>
12:43:30.822229 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.100.2186 > 192.168.1.101.3128: R, cksum 0xad4d (correct), 1779957663:1779957663(0) win 0
Using spoofed source:
Code:
12:46:35.375545 IP (tos 0x0, ttl 64, id 49844, offset 0, flags [none], proto TCP (6), length 40) 127.0.0.1.1103 > 192.168.1.101.3128: S, cksum 0xabe8 (correct), 1607516672:1607516672(0) win 512

Throwing a single SYN packet at a port with nothing listening:

Using real source:
Code:
13:22:22.830001 IP (tos 0x0, ttl 64, id 23168, offset 0, flags [none], proto TCP (6), length 40) 192.168.1.100.2073 > 192.168.1.101.666: S, cksum 0x50cb (correct), 256065977:256065977(0) win 512
13:22:22.830322 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.101.666 > 192.168.1.100.2073: R, cksum 0xd006 (correct), 0:0(0) ack 256065978 win 0
Using spoofed source:
Code:
13:25:37.088693 IP (tos 0x0, ttl 64, id 36207, offset 0, flags [none], proto TCP (6), length 40) 127.0.0.1.1602 > 192.168.1.101.666: S, cksum 0xfb25 (correct), 555859947:555859947(0) win 512

Last edited by win32sux; 12-03-2008 at 01:55 PM.
 
Old 12-03-2008, 02:18 PM   #9
irey
Member
 
Registered: Jun 2008
Location: Torino, Italy
Posts: 65

Original Poster
Rep: Reputation: 17
Alright, I took a look at the kernel sources.

Code:
net/ipv4/route.c:1769

if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr))
    goto martian_source;
This is ip_route_input_slow(), which is called after a packet is received. There is also a comment at the beggining of this function saying that spoofing attacks are prevented here (I guess the rp_filter stuff applies to external IP addresses only, not 127.0.0.1).

By taking a look at the martian_source tag I see that the strange packet may be logged at warning level. However you may not see it in your kernel logs since it depends on many conditions, including kernel config.

Now I feel more than safe that my servlet won't be called from the outside world. Thanks!
 
Old 12-08-2008, 08:40 PM   #10
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Hi there. Just following up on this (sorry for the delay).

Based on your previous post, I enabled martian logging and re-tested.

To enable martian logging I did a (on the target):
Code:
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
The spoofed packet now gets logged (regardless of whether the port it hits has something listening on it or not).

This is what /var/log/syslog looks like upon packet arrival:
Code:
Dec  8 20:18:12 labrat kernel: [ 2449.241998] martian source 192.168.1.101 from 127.0.0.1, on dev eth0
Dec  8 20:18:12 labrat kernel: [ 2449.242011] ll header: 03:0E:94:bc:8c:03:03:e8:e5:b3:c8:bf:08:00
So I confirm Linux seems to properly deal with spoofed packets having a 127.0.0.1 source address.

Last edited by win32sux; 12-08-2008 at 08:43 PM.
 
Old 12-09-2008, 04:53 AM   #11
irey
Member
 
Registered: Jun 2008
Location: Torino, Italy
Posts: 65

Original Poster
Rep: Reputation: 17
That's cool! You're right about win32, we'd never be able to find out our answers from the source in this way.

Thanks again.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Sendmail : relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refuse macadam Linux - Software 0 09-23-2007 02:44 PM
mailer=relay, pri=30008, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Con pralhad Linux - Software 1 08-11-2007 10:49 AM
Spoofed emails? twantrd Linux - Security 1 07-05-2006 08:14 PM
DSN: Data format error & relay=[127.0.0.1] [127.0.0.1] calmbomb Linux - Software 0 11-07-2004 03:24 PM
spoofed packeting exigent Linux - Security 3 11-24-2002 03:57 PM


All times are GMT -5. The time now is 02:15 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration