Linux Kernel 2.2.x ISN vulnerability makes the kernel vulnerable
to blind TCP spoofing
----------------------------------------------------------------------------
----
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.
DETAILS
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>
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:
__u32 secure_tcp_sequence_number(__u32 saddr, __u32 daddr,
__u16 sport, __u16 dport)
{
...
static __u32 secret[12];
...
secret[0]=saddr;
secret[1]=daddr;
secret[2]=(sport << 16) + dport;
seq = (halfMD4Transform(secret+8, secret) &
((1<<HASH_BITS)-1)) + count;
...
}
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.
Solution:
There was a "fix" posted to the kernel mailing list (
<http://kernelnotes.org/lnxlists/linux-kernel/lk_9909_04/msg00664.html>
http://kernelnotes.org/lnxlists/linux-kernel/lk_9909_04/msg00664.html ),
which solves the problem. For those who do not wish to use 2.2.13preX this
can be solution.
ADDITIONAL INFORMATION
This vulnerability has been discovered by: Stealth and S.Krahmer.
-------
AFLHI 058009990407128029/089802
milis ini didukung oleh :
>> http://www.indolinux.com - dunia linux indonesia
-------------------------------------------------------------------
untuk berhenti kirim email ke [EMAIL PROTECTED]
untuk melihat peraturan kirim email ke [EMAIL PROTECTED]
arsip berada di http://www.mail-archive.com/[email protected]
