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
