======================================================================= Network Associates, Inc. SECURITY ADVISORY March 9, 1999 Linux Blind TCP Spoofing ======================================================================= SYNOPSIS An implementation flaw in the Linux TCP/IP stack allows remote attackers to forge TCP connections without predicting sequence numbers and pass data to the application layer before a connection is established. ======================================================================= VULNERABLE HOSTS This problem is present in Linux kernels up to and including 2.0.35. Any distribution containing a kernel revision less than this is vulnerable. ======================================================================= DETAILS TCP is a reliable connection-oriented protocol which requires the completion of a three way handshake to establish a connection. To implement reliable and unduplicated delivery of data, the TCP protocol uses a sequence based acknowledgment system. During connection establishment each host selects an initial sequence number which is sent in the first packet of the connection. Each subsequent byte transmitted in the TCP connection is assigned a sequence number. To prevent duplicate or invalid segments from impacting established connections TCP utilizes a state based model. In a typical client-server application, the client initiates a connection by transmitting a TCP segment to a listening server process. This causes the state of the process to move from the LISTEN state into SYN_RECEIVE if a SYN flag is present. During this state the server acknowledges the clients request setting both the SYN and ACK flags. To complete the three way handshake the client acknowledges the servers response, moving the server from SYN_RECEIVE to ESTABLISHED state. To establish a forged TCP session an attacker must have knowledge of or be able to predict the initial sequence number that is selected by the server. An implementation flaw in the Linux kernel allows data to be delivered to the application layer before the handshake has completed. ======================================================================= TECHNICAL DETAILS The combination of three flaws in the Linux TCP/IP implementation contribute to the existence of a security vulnerability. Firstly, Linux only verifies the acknowledgment number of incoming segments if the ACK flag has been set. Linux also queues data from TCP segments without acknowledgment information prior to the completion of the three way handshake but after the initial SYN has been acknowledged by the server. Finally, Linux passes data to the application layer upon the receipt of a packet containing the FIN flag regardless of whether a connection has been established. Together, these flaws allow an attacker to spoof an arbitrary connection and deliver data to an application without the need to predict the servers initial sequence number. According to the standard, there is only one case wherein a correct TCP/IP stack can accept data in a packet that does not have the ACK flag set --- the initial connection-soliciting SYN packet can contain data, but must not have the ACK flag set. In any other case, a data packet not bearing the ACK flag should be discarded. When a TCP segment carries an ACK flag, it must have a correct acknowledgement sequence number (which is the sequence number of the next byte of data expected from the other side of the connection). TCP packets bearing the ACK flag are verified to ensure that their acknowledgement numbers are correct. Vulnerable Linux kernels accept data segments that do not have the ACK flag set. Because the ACK flag is not set, the acknowledgement sequence number is not verified. This allows an attacker to send data over a spoofed connection without knowing the target's current (or initial) sequence number. Linux does not deliver data received from a TCP connection when the connection is in SYN_RECEIVE state. Thus, an attacker cannot successfully spoof a TCP transaction to a Linux host without somehow completing the TCP handshake. However, an implementation flaw in some Linux kernels allows an attacker to bypass the TCP handshake entirely, by "prematurely" closing it with a FIN packet. When a FIN packet is received for a connection in SYN_RECEIVE state, Linux behaves as if the connection was in ESTABLISHED state and moves the connection to CLOSE_WAIT state. In the process of doing this, data queued on the connection will be delivered to listening applications. If the ACK flag is not set on the FIN segment, the target's sequence number is not verified in the segment. ======================================================================= RESOLUTION It is recommended that kernels below version 2.0.36 be upgraded to eliminate this vulnerability. Updated kernel packages for Red Hat Linux which are not vulnerable to this problem are available from http://www.redhat.com/support/docs/errata.html. Both Debian and Caldera Linux have been contacted regarding this vulnerability although no official response has been received. The latest stable versions of the Linux kernel are available from http://www.kernel.org. ======================================================================= CREDITS Analysis and documentation of this problem was conducted by Anthony Osborne with the Security Labs at Network Associates. This vulnerability was discovered on the October 5, 1998. ======================================================================= ABOUT THE NETWORK ASSOCIATES SECURITY LABS The Security Labs at Network Associates hosts some of the most important research in computer security today. With over 30 published security advisories published in the last 2 years, the Network Associates security auditing teams have been responsible for the discovery of many of the Internet's most serious security flaws. This advisory represents our ongoing commitment to provide critical information to the security community. For more information about the Security Labs at Network Associates, see our website at http://www.nai.com or contact us at <seclabs@nai.com>.
As posted to BUGTRAQ by Security Research Labs on Mar 9th,
1999. -lt ed