> 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
