Date: Tue, 14 Mar 2006 10:33:02 +0100 (CET)
From: Marco Ivaldi <raptor@0xdeadbeef.info.>
To: [email protected]Subject: Linux zero IP ID vulnerability?
Message-ID: <Pine.BSO.4.58.0603141008290.27645@voodoo.mediaservice.net.>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: antivirus-gw at tyumen.ru
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@pandora:~# 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@pandora:~# 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@pandora:~# 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@pandora:~# 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
