Re: Linux zero IP ID vulnerability?
> Hi Marco!
Hey Andrea,
> - [PIRELLI HOME ACCESS GATEWAY]
Based on your tests, this device shows the standard incremental IP ID
behaviour: so, nothing special here.
> - [MY BOX WITH 2.6.15.6 #1 i686 pentium4 GNU/Linux (vanilla)]
[snip]
> (closed port + S flag)
> bunker@syn:~$ cat hping.closed
> HPING xxx.xxx.xxx.139 (eth0 xxx.xxx.xxx.139): S set, 40 headers
> len=46 ip=xxx.xxx.xxx.139 ttl=64 DF id=4102 sport=18 flags=RA seq=0
> win = 0
> len=46 ip=xxx.xxx.xxx.139 ttl=64 DF id=4103 sport=18 flags=RA seq=1
> win=0
> len=46 ip=xxx.xxx.xxx.139 ttl=64 DF id=4104 sport=18 flags=RA seq=2
> win=0
Yeah, you're right. Also closed ports (returning a TCP RST to both SYN and
SYNACK) show the flawed behaviour i've observed, and can of course be used
to perform an idle scan with nmap, e.g.:
root@pandora:~# hping -S research.mediaservice.net -p 563 -c 1
HPING research.mediaservice.net (eth0 82.56.144.13): S set, 40 headers + 0
data bytes
len=46 ip=82.56.144.13 ttl=59 DF id=31911 sport=563 flags=RA seq=0 win=0
rtt=83.9 ms
--- research.mediaservice.net hping statistic ---
1 packets tramitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 83.9/83.9/83.9 ms
root@pandora:~# nmap -sI research.mediaservice.net:563 target -p 21-25
WARNING: Many people use -P0 w/Idlescan to prevent pings from their true
IP. On the other hand, timing info Nmap gains from pings can allow for
faster, more reliable scans.
Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-03-17 12:42
CET
Idlescan using zombie research.mediaservice.net (82.56.144.13:563); Class:
Incremental
Interesting ports on target (x.x.x.x):
PORT STATE SERVICE
21/tcp closed|filtered ftp
22/tcp open ssh
23/tcp closed|filtered telnet
24/tcp closed|filtered priv-mail
25/tcp open smtp
Nmap finished: 1 IP address (1 host up) scanned in 6.927 seconds
After further testing, i confirm that Linux 2.6 seems to be vunerable in
every configuration i've seen so far. Since i didn't get any feedback yet
from the Linux kernel developers nor from Cisco (other vendors may also be
affected) i've the feeling they're not going to fix this any soon: in the
next days i'll see if i can find some spare time to dig a bit into kernel
code to identify the cause and maybe even provide a patch.
Cheers,
--
Marco Ivaldi
Antifork Research, Inc. http://0xdeadbeef.info/
3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707