Linux Blind TCP Spoofing Vulnerability
BID:580
Info
Linux Blind TCP Spoofing Vulnerability
| Bugtraq ID: | 580 |
| Class: | Serialization Error |
| CVE: | |
| Remote: | Yes |
| Local: | No |
| Published: | Jul 31 1999 12:00AM |
| Updated: | Jul 31 1999 12:00AM |
| Credit: | Originally posted to Bugtraq July 31, 1999 by Nergal <[email protected]>, with much additional valuable commentary by many others. See the references. |
| Vulnerable: |
Linux kernel 2.0.37 Linux kernel 2.0.36 Linux kernel 2.0.35 Linux kernel 2.0.30 |
| Not Vulnerable: |
Linux kernel 2.0.34 Linux kernel 2.0.33 |
Discussion
Linux Blind TCP Spoofing Vulnerability
Certain Linux kernels in the 2.0.3x range are susceptible to blind TCP spoofing attacks due to the way that the kernel handles invalid ack sequence numbers, and the way it assigns IDs to outgoing IP datagrams. For this vulnerability to be effective, 3 conditions have to be met: The spoofed machine must be off the network or incapable of sending data out/recieving data properly, the target machine must not be communicating actively with any other machines at the time, and no packets between the attacker's machine and the target can be dropped during the attack.
The reason this can be done is firstly due to how these kernels handle invalid ack_seq numbers. If a connection has not been established, a packet with an ack_seq too low will be ignored, and a packet with an ack_seq too high will be responded to with a reset packet. If a connection has been established, any invalid ack_seq is ignored. Whether or not a reply packet has been generated can be determined by sending ICMP echo requests, with the attacker's real IP address as the source. Linux assigns sequnetial IP IDs to all outgoing packets. Therefore, by sending an ICMP echo request probe between each spoofed packet, it is possible to determine how many packets were generated in reply to the spoof attempt.
Therefore: ICMP echo request is sent, and reply received with id=i. If a spoof attempt is made with ack_seq = a, and the next ICMP reply has an id of i+1, then no reply was generated from the spoof attempt and ack_seq is too low. However, if the ICMP reply has an id of i+2, then a response was generated and ack_seq is either too high, (reset packet sent by target) or correct (connection established). To determine which is true, another spoofed packet is sent, with a known-high ack_seq, followed by another ICMP probe. If the response to this probe has an ID incremented by two, then the known-high ack_seq resulted in a reset packet being sent, so the connection has not been successfully established. If the ICMP reply has an ID incremented by one, the known-high ack_seq was ignored, meaning that the connection has been established and the blind spoof can continue.
Certain Linux kernels in the 2.0.3x range are susceptible to blind TCP spoofing attacks due to the way that the kernel handles invalid ack sequence numbers, and the way it assigns IDs to outgoing IP datagrams. For this vulnerability to be effective, 3 conditions have to be met: The spoofed machine must be off the network or incapable of sending data out/recieving data properly, the target machine must not be communicating actively with any other machines at the time, and no packets between the attacker's machine and the target can be dropped during the attack.
The reason this can be done is firstly due to how these kernels handle invalid ack_seq numbers. If a connection has not been established, a packet with an ack_seq too low will be ignored, and a packet with an ack_seq too high will be responded to with a reset packet. If a connection has been established, any invalid ack_seq is ignored. Whether or not a reply packet has been generated can be determined by sending ICMP echo requests, with the attacker's real IP address as the source. Linux assigns sequnetial IP IDs to all outgoing packets. Therefore, by sending an ICMP echo request probe between each spoofed packet, it is possible to determine how many packets were generated in reply to the spoof attempt.
Therefore: ICMP echo request is sent, and reply received with id=i. If a spoof attempt is made with ack_seq = a, and the next ICMP reply has an id of i+1, then no reply was generated from the spoof attempt and ack_seq is too low. However, if the ICMP reply has an id of i+2, then a response was generated and ack_seq is either too high, (reset packet sent by target) or correct (connection established). To determine which is true, another spoofed packet is sent, with a known-high ack_seq, followed by another ICMP probe. If the response to this probe has an ID incremented by two, then the known-high ack_seq resulted in a reset packet being sent, so the connection has not been successfully established. If the ICMP reply has an ID incremented by one, the known-high ack_seq was ignored, meaning that the connection has been established and the blind spoof can continue.
Exploit / POC
Solution / Fix
Linux Blind TCP Spoofing Vulnerability
Solution:
This issue was patched in kernel 2.0.33 and fixed in 2.0.34, but the problem was re-introduced in 2.0.36 .
In an email to Bugtraq on August 10, Salvatore Sanfilippo -antirez- <[email protected]> mentioned that he is working on a patch for this, and will post it to Bugtraq when it is complete.
Solar Designer has written a patch for 2.0.37, which is available from:
http://www.false.com/security/linux/
Solution:
This issue was patched in kernel 2.0.33 and fixed in 2.0.34, but the problem was re-introduced in 2.0.36 .
In an email to Bugtraq on August 10, Salvatore Sanfilippo -antirez- <[email protected]> mentioned that he is working on a patch for this, and will post it to Bugtraq when it is complete.
Solar Designer has written a patch for 2.0.37, which is available from:
http://www.false.com/security/linux/
References
Linux Blind TCP Spoofing Vulnerability
References:
References: