Linux Kernel 2.2.x ISN vulnerability makes the kernel vulnerable to blind TCP spoofing
6 Oct. 1999
Summary
A weakness in the TCP stack in Linux 2.2.x kernels has been discovered. This vulnerability makes it possible to "blind-spoof" TCP connections. It's therefore possible for an attacker to initiate a TCP connection from an arbitrary non-existing or non-responding IP source address, exploiting IP address based access control mechanisms.
Linux 2.0.x kernels were tested against this attack and found not to be vulnerable in any case.
Credit:
This vulnerability has been discovered by: Stealth and S.Krahmer.
Systems Affected:
All systems running kernel versions 2.2.x of the Linux operating system. Linux 2.3.x systems also may be affected.
Apparently, it doesn't matter whether the TCP syncookie functionality was enabled or not (enabled within the kernel and activated through the proc filesystem options).
Tests:
This is the beginning of a log of a successfully mounted blind TCP spoofing attack against a Linux 2.2.12 system. (Tcpdump output formatted for better readability)
16:23:02.727540 attacker.522 > victim.ssh : S 446679473: 446679473(0)
16:23:02.728371 victim.ssh > attacker.522: S 3929852318:3929852318(0)
16:23:02.734448 11.11.11.11.522 > victim.ssh: S 446679473: 446679473(0)
16:23:02.734599 victim.ssh > 11.11.11.11.522: S 3929859164:3929859164(0)
16:23:03.014941 attacker.522 > victim.ssh: R 446679474: 446679474(0)
16:23:05.983368 victim.ssh > 11.11.11.11.522: S 3929859164:3929859164(0)
16:23:06.473192 11.11.11.11.522 > victim.ssh: . ack 3929855318
16:23:06.473427 victim.ssh > 11.11.11.11.522: R 3929855318:3929855318(0)
16:23:06.554958 11.11.11.11.522 > victim.ssh: . ack 3929855319
16:23:06.555119 victim.ssh > 11.11.11.11.522: R 3929855319:3929855319(0)
16:23:06.637731 11.11.11.11.522 > victim.ssh: . ack 3929855320
16:23:06.637909 victim.ssh > 11.11.11.11.522: R 3929855320:3929855320(0)
..
The first ISN of the victim's host is 3929852318, which is within a SYNACK packet to the attackers host. This is unspoofed and can be easily snagged by the attacker. At the same time the attacker sent out the first unspoofed SYN packet he sent a spoofed SYN packet from 11.11.11.11 too. This packet is answered by the victim host as well, with the ISN of 3929859164. The difference between the first visible ISN and the second ISN is only (3929859164-3929852318) = 6846.
Please notice that all TCP and IP parameters of the spoofed packet, except for the IP source address are the same as of the unspoofed packet. This is important (see below).
This small difference within the initial TCP sequence number (ISN) is exploitable. In other tests, where both hosts were unlagged there were differences below 500 in some cases.
Impact:
By sending packets from a trusted source address, attackers could possibly bypass address based authentication and security mechanisms.
There have been similar exploiting techniques, aimed especially at r* and NFS services, in the past that demonstrated the security impact of weak ISNs very well. A working exploit to demonstrate the weakness can be downloaded from: http://teso.scene.at/releases/adv1.tar.gz.
Explanation:
The problem relies on a implementation flaw within the random ISN algorithm in the Linux kernel.
The problem is within drivers/char/random.c, line 1684:
As already said, in our spoofed TCP SYN packet only the IP source address differs, that is only secret[0], so of 12*4 random bytes used to create the sequence number from, only 4 bytes differ. Obviously the hash created by halfMD4Transform has similarities if the source and destination ports and the destination address are the same.
It seems that the src-adress is least-significant to the above MD4 algorithm. Changing the source-ports too, makes the 2 ISNs more differ. Due to the short gap of time, the last
seq += tv.tv_usec + tv.tv_sec*1000000;
is useless. This may be the reason why this bug may have survived long: In any real network situation it is uncommon that the source and destination ports are equal in two different connections on one host.
Further analysis of the hash algorithm in this routine may result in a better ISN prediction.
