spoofing.tcp.blind.linux.txt

`Date: Tue, 9 Mar 1999 16:28:24 -0800  
From: Security Research Labs <[email protected]>  
To: [email protected]  
Subject: Linux Blind TCP Spoofing  
  
[ The following text is in the "iso-8859-1" character set. ]  
[ Your display is set for the "US-ASCII" character set. ]  
[ Some characters may be displayed incorrectly. ]  
  
-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1  
  
======================================================================  
=  
  
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  
<[email protected]>.  
  
======================================================================  
=  
  
NETWORK ASSOCIATES SECURITY LABS PGP KEY  
  
- -----BEGIN PGP PUBLIC KEY BLOCK-----  
Version: PGP 5.5.5  
  
mQGiBDXGgDsRBADVOnID6BtEhKlm2cNalho28YP0JAh+J4iRUIaiWshzI0tc0KPc  
fvs+0xYwiqjxmeHi2sdIEPQ7S+ltA3Dlp6/DFojWBr2XB9hfWy4uiKBUHqnsKYnB  
Gpkh6nIx7DIwn+u0PXMXbJCG3LYf8daiPVdzC2VFtbRvJL4wZc6NLQViFQCg/9uS  
DuH/0NE6mO8Cu4iVrUT5Wk8D/ArOpV5T5yIuXHZO1/ZBVeHccVVvHe8wHK4D9WUs  
FsB8fgYLNgdFMMjtam7QQSBY/P1KKBzaFqZhkfS4WVMAFEy94NHXG+KTCPhXkZzp  
OPPqwWqZgfvOg0Bm20O/GhzQkB6JfFJqcfR87Ej0+fcDKrTTxAELWHGS7c9Qdn6P  
bfwHA/4oLNwYrtgWNkjGcG018Pu2jKT7YuP9zBTMu28IBiWdPLGL9Wle4d5cdDVx  
Es4iVl8FMtxlgTWCgMnBLS4nyM3pCn1HF+8Gi+IVKUXWCkqt/rtBMsrOMfrOgEIu  
BWnTZcTR7kcWtH7xDFNyZ47U4pElLXwATVDty/FczAJnpeht2LQyTmV0d29yayBB  
c3NvY2lhdGVzIFNlY3VyaXR5IExhYnMgPHNlY2xhYnNAbmFpLmNvbT6JAEsEEBEC  
AAsFAjXGgDsECwMCAQAKCRCheCy6j9WBEtgDAKDpYMwQZP0Ipx7X0ivnTxxJkA/W  
vACg4LZv0lmWqmnd7XCe4OIJ05aT6hK5Ag0ENcaAOxAIAPZCV7cIfwgXcqK61qlC  
8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh  
01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscB  
qtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFst  
jvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISn  
CnLWhsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVeky  
CzsAAgIH/RZcJoRkhCf9O4Er+rciBNG3QqM3tek23oxGuVwqRxtGlGKuf+YaUDIA  
vZhARftupZYJf/+AM9pyjjsF7ON/Df5oIXXhqzrDySw47dNB3I1FG7vwAUBRfYgG  
NRP+zvf1nld+FgAXag1DIQteXYPtoMUJP8ZgvbELYVdZS2TapOHUv7r4rOY+UUjl  
U+FkQPp9KCNreaNux4NxwT3tzXl1KqqkliC8sYxvMCkJ+JO71TKGplO9dXsf3O8p  
2r33+LngmLs4O7inrUlmAUKq3jmCK50J7RsZjd6PlK/0JwcjFkOZeYrxTguZzCR4  
QYmo8nEHqEMSKQci0VUf9KH4lHf6xmGJAEYEGBECAAYFAjXGgDsACgkQoXgsuo/V  
gRK5LACgoAqLFk10kAMu6xb3ftO4+INJs14Ani+1hujlYRxYphN97c5ci8WtILNZ  
=L3C6  
- ----  
-----BEGIN PGP SIGNATURE-----  
Version: PGP for Personal Privacy 5.0  
Charset: noconv  
  
iQA/AwUBNvLqq6F4LLqP1YESEQJH5QCg4FIv1+eRED+wYV5uMp2nVto/zHMAnjii  
g3Q3t36ITPBKkdRCQGK4DCBe  
=yLGh  
-----END PGP SIGNATURE-----  
  
--------------------------------------------------------------------------  
  
Date: Wed, 10 Mar 1999 12:17:25 -0800  
From: John D. Hardin <[email protected]>  
To: [email protected]  
Subject: Re: Linux Blind TCP Spoofing (fwd)  
  
---------- Forwarded message ----------  
Date: Wed, 10 Mar 1999 19:46:13 +0000 (GMT)  
>From: Alan Cox <[email protected]>  
To: [email protected]  
Subject: Re: Linux Blind TCP Spoofing  
  
> > It is recommended that kernels below version 2.0.36 be upgraded to  
> > eliminate this vulnerability.  
>  
> This implies but does not explicitly state that 2.0.36+ kernels are  
> not vulnerable. Is this the case?  
  
NAI reported the problem to me during the 2.0.36 development period and  
the bug was squashed.  
  
`