Re: Linux zero IP ID vulnerability?

[Marco Ivaldi <raptor () 0xdeadbeef info>]

> 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