bugtraq - 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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Tue, 14 Mar 2006 10:33:02 +0100 (CET)
From: Marco Ivaldi <raptor@...eadbeef.info>
To: bugtraq@...urityfocus.com
Subject: Linux zero IP ID vulnerability?

Hello Bugtraq,

I've recently stumbled upon an interesting behaviour of some Linux kernels
that may be exploited by a remote attacker to abuse the ID field of IP
packets, effectively bypassing the zero IP ID in DF packets countermeasure
implemented since 2.4.8 (IIRC).

This is the correct behaviour:

root@...dora:~# hping -S localhost -p 22
HPING localhost (lo 127.0.0.1): S set, 40 headers + 0 data bytes
len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=0 win=32767 
rtt=0.1 ms
len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=1 win=32767 
rtt=0.0 ms
len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=2 win=32767 
rtt=0.0 ms

--- localhost hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.1/0.1 ms
root@...dora:~# hping -SA localhost -p 22
HPING localhost (lo 127.0.0.1): SA set, 40 headers + 0 data bytes
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=R seq=0 win=0 rtt=0.1 ms
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=R seq=1 win=0 rtt=0.0 ms
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=R seq=2 win=0 rtt=0.0 ms

--- localhost hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.1/0.1 ms

This is the flawed behaviour:

root@...dora:~# hping -S vuln -p 22
HPING vuln (eth0 x.x.x.x): S set, 40 headers + 0 data bytes
len=46 ip=x.x.x.x ttl=59 DF id=0 sport=22 flags=SA seq=0 win=5808 rtt=56.4 
ms
len=46 ip=x.x.x.x ttl=59 DF id=0 sport=22 flags=SA seq=1 win=5808 rtt=72.7 
ms
len=46 ip=x.x.x.x ttl=59 DF id=0 sport=22 flags=SA seq=2 win=5808 rtt=64.7 
ms

--- vuln hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 56.4/64.6/72.7 ms
root@...dora:~# hping -SA vuln -p 22
HPING vuln (eth0 x.x.x.x): SA set, 40 headers + 0 data 
bytes
len=46 ip=x.x.x.x ttl=59 DF id=4248 sport=22 flags=R seq=0 win=0 rtt=143.6 
ms
len=46 ip=x.x.x.x ttl=59 DF id=4253 sport=22 flags=R seq=1 win=0 rtt=174.8 
ms
len=46 ip=x.x.x.x ttl=59 DF id=4258 sport=22 flags=R seq=2 win=0 rtt=200.4 
ms

--- vuln hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 143.6/172.9/200.4 ms

As you can see, in the second case the replies to TCP SYN packets contain
a correct IP ID value of zero, but replies to TCP SYNACK packets have an
incremental IP ID field instead: this means a remote attacker can abuse
this behaviour for malicious purposes (i.e. to perform an idle scan with
nmap).

Specifically, the latest nmap (v4.01) fails to correctly identify this
TCP/IP stack behaviour (it reports "IPID Seq: All zeros"), but it's able
to exploit it without code modifications. This is due to the fact that
nmap "-O -v" apparently checks the IP ID field against TCP SYN packets
only, while nmap "-sI" actually uses TCP SYNACK.

So far, i haven't gathered enough data to identify the root cause of this 
problem, but all 2.6 kernels seem to be affected, while only some 2.4 are
vulnerable. Here are the preliminary results of my tests (note that some 
versions of Cisco IOS also show the flawed behaviour):

[Vulnerable]

Linux 2.6.15-gentoo-r1 (Gentoo current)
Linux 2.6.14-gentoo-r5 + grsec (Gentoo)
Linux 2.6.8.1 (Debian 3.0)
Linux 2.4.27-2-686-smp (Debian 3.1)
Some Cisco routers (at least IOS 12.2)

[Not vulnerable]

Linux 2.4.32-ow1 (Slackware 10.1)
Linux 2.4.32-ow1 (Owl 2.0-release)
Linux 2.4.31 (Slackware 10.2)
Linux 2.4.26 (Slackware 9.1.0)

As Philippe Biondi pointed out while privately discussing this issue,
there is the same problem (ID present and incremental) for UDP and ICMP
packets. The interesting thing with TCP, though, is that it can be
exploited to perform an idle scan, while i don't see security implications
with UDP and ICMP, despite the obvious information leak.

Cheers,

-- 
Marco Ivaldi
Antifork Research, Inc.   http://0xdeadbeef.info/
3B05 C9C5 A2DE C3D7 4233  0394 EF85 2008 DBFD B707