bugtraq - Re: Linux zero IP ID vulnerability?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date: Fri, 17 Mar 2006 12:49:03 +0100 (CET)
From: Marco Ivaldi <raptor@...eadbeef.info>
To: bugtraq@...urityfocus.com
Cc: Andrea Purificato - bunker <bunker@...twebnet.it>
Subject: 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@...dora:~# 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@...dora:~# 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