Vulnerability Issues in TCP
|| 20 April 2004
||20 April 2004
What is Affected?
The vulnerability described in this advisory affects implementations
of the Transmission Control Protocol (TCP) that comply with
the Internet Engineering
Task Force's (IETF's) Requests For Comments (RFCs) for TCP, including RFC
original specification, and RFC
1323, TCP Extensions for High Performance.
TCP is a core network protocol used in the majority of networked computer systems
today. Many vendors include support for this protocol in their products and may
be impacted to varying degrees. Furthermore any network service or application
that relies on a TCP connection will also be impacted, the severity depending
primarily on the duration of the TCP session.
The impact of this vulnerability varies by vendor and application, but in some
deployment scenarios it is rated critical. Please see the vendor section below
for further information. Alternatively contact your vendor for product specific
If exploited, the vulnerability could allow an attacker to create a Denial of
Service condition against existing TCP connections, resulting in premature session
termination. The resulting session termination will affect the application layer,
the nature and severity of the effects being dependent on the application layer
protocol. The primary dependency is on the duration of the TCP connection, with
a further dependency on knowledge of the network (IP) addresses of the end points
of the TCP connection.
The Border Gateway Protocol (BGP) is judged to be potentially most affected by
BGP relies on a persistent TCP session between BGP peers. Resetting the connection
can result in medium term unavailability due to the need to rebuild routing tables
and route flapping. Route flapping may result in route dampening (suppression)
if the route flaps occur frequently within a short time interval. The overall
impact on BGP is likely to be moderate based on the likelihood of successful
attack. If the TCP MD5 Signature Option and anti-spoofing measures are used then
the impact will be low as these measures will successfully mitigate the
There is a potential impact on other application protocols such as DNS (Domain
Name System) and SSL (Secure Sockets Layer) in the case of zone transfers and
ecommerce transactions respectively, but the duration of the sessions is relatively
short and the sessions can be restarted without medium term unavailability problems.
In the case of SSL it may be difficult to guess the
source IP address.
Data injection may be possible. However, this has not been demonstrated and appears
to be problematic.
The issue described in this advisory is the practicability of resetting an established
TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise)
The packets need to have source and destination IP addresses that match the established
connection as well as the same source
and destination TCP ports.
The fact that TCP sessions can be reset by sending suitable RST and SYN packets
is a design feature of TCP according to RFC
793, but a reset attack is only possible at all because the source IP address
port can be forged or "spoofed".
Although denial of service using crafted TCP packets is a well known weakness
of TCP, until recently it was believed that a successful denial of service attack
was not achievable in practice. The reason for this is that the receiving TCP
implementation checks the sequence number of the RST or SYN packet, which is
a 32 bit number, giving a probability of 1/232 of
guessing the sequence number correctly (assuming a random distribution).
The discoverer of the practicability of the RST attack was Paul A. Watson, who
describes his research in his paper "Slipping In The Window: TCP Reset Attacks",
presented at the CanSecWest 2004 conference. He noticed that the probability
guessing an acceptable sequence number is much higher than 1/232 because
the receiving TCP implementation will accept any sequence number in a certain
(or "window") of the expected sequence number. The window makes TCP reset attacks
Any application protocol which relies on long term TCP connections and for which
the source and destination IP addresses and TCP ports are known or can be easily
guessed will be vulnerable to at least denial of
TCP is the transport layer protocol designed to provide connection-oriented reliable
delivery of IP packets. To do this TCP uses a mixture of flags, to indicate state,
and sequence numbers, to identify the order in which the packets
are to be reassembled.
TCP also provides a number, called an acknowledgement number, that is used to
indicate the sequence number of the next packet expected. The packets are reassembled
by the receiving TCP implementation only if their sequence numbers fall within
a range of the acknowledgement number (called a "window"). The acknowledgement
number is not used in a RST packet because a reset does not expect a packet in
return. (To be completely accurate, although the last statement is true for a
RST packet without the ACK flag set, used to indicate that a TCP port is closed,
a RST/ACK is used to terminate an active connection in the event of error. In
a RST/ACK packet an acknowledgement number is included in the packet, although
it is not checked by the receiving TCP implementation.)
RFC 793, p36, states the following:
"In all states except SYN-SENT, all reset (RST) segments are validated by
checking their SEQ-fields [sequence numbers]. A reset is valid if its sequence
number is in the window. In the SYN-SENT state (a RST received in response to
initial SYN), the RST is acceptable if the ACK field acknowledges the SYN."
Resets must be processed immediately. RFC
793, p25, says "[.] [E]ven when the receive window is zero, a TCP must
process the RST and URG fields of all
It is also possible to perform the same attack with SYN (synchronise) packets.
An established connection will abort by sending a RST if it receives a duplicate
SYN packet with initial sequence number within the TCP window. RFC
"The principle reason for the three-way handshake is to prevent old duplicate
connection initiations from causing confusion. To deal with this, a special control
message, reset, has been devised. [.] If the TCP is in one of the synchronized
states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
it aborts the connection and informs its user."
TCP window sizes are negotiated in the initial 3-way handshake used to set up
a TCP connection, with higher values serving to improve throughput in some circumstances.
Vendor-chosen defaults also influence the selection. In any case, the larger
the window size, the greater is the probability that a randomly chosen TCP sequence
number will lie within the window range. This is the basis
for the attack.
A TCP connection is defined by a 4-tuple comprising source and destination IP
addresses, and source and destination ports. An attacker seeking to disrupt an
existing TCP connection must supply the 4-tuple correctly. As the source port
varies, additional work is generally called for on the part of the attacker.
However, research (referenced below) has shown that the process of source port
selection on many platforms includes predictable elements, so that the attack
remains practicable. By weighting 'likely' source port values carefully, an attacker
can disrupt TCP implementations that employ a range of window sizes.
Application layer protocols that are critically affected are those that:
||Depend on long lived TCP connections
||Have known or easy-to-guess IP address end points
||Have easy to an easy-to-guess source TCP port
As noted above BGP does
use long lived TCP connections, and the IP addresses and source port (and
port) are sometimes available through the
use of BGP looking glasses (multi-source, multi-destination trace route tools)
or DNS resource records. Using "trace route" commands can provide information
on peering point IP addresses. Thus BGP is likely to be critically affected
by the TCP vulnerability.
These denial of service attacks can be carried out by single machine, or by
multiple co-operating systems (to form a distributed denial of service attack).
It is also possible to inject packets, which will be processed if they are
in the window. The difficulty with data injection attacks is that the receiving
TCP implementation will reassemble the packets received according to sequence
number, dropping any duplicate packets.
Vendor specific information will be released as it becomes available and if
vendor permission has been received. Subscribers are advised to check the following
URL regularly for updates:
[Please note that updates to this advisory will not be notified by email.]
This vulnerability has been assigned the CVE name CAN-2004-0230.
The Open Source Vulnerability Database ID
number for this vulnerability is 4030.
The following mitigation steps are still being evaluated and may be incomplete.
Customers should work with vendors for the workaround most appropriate for
the product in question.
In the absence of vendor patching of the TCP implementation, the following
are general mitigating steps:
||Implement IP Security (IPSEC) which will encrypt traffic
at the network layer, so TCP information will not be visible
||Reduce the TCP window size (although this could increase
traffic loss and subsequent retransmission)
||Do not publish TCP source port information
It should be noted that
IPSEC provides confidentiality and authentication services at the network
layer, and can
provide a measure of trust in the authenticity
of the end points as well as encryption of traffic between the end points. However,
in the context of the current attack IPSEC will reject RST and SYN packets
that are not part of a secure IP packet stream.
To change the TCP window size, in some Unix variants you can set a value of
the default TCP windows size by using the "sysctl" program ("ndd -set" in the
case of Sun Solaris). In the case of Microsoft Windows NT/2000/XP/2003, the
default window size can be changed by modifying the value of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
key. As noted above, great care should be exercised when altering the default
TCP window size as network performance could be adversely affected.
In the case of BGP, the following may counter the problem:
||Implement ingress and egress filtering to check that the
traffic entering or leaving the network has a source IP address that is
expected on the router/firewall interface that receives the traffic
||Implement the TCP MD5 Signature Option to checksum the TCP
packet carrying the BGP application data (see RFC
2385), being careful to set and maintain strong (i.e. difficult to
guess) passwords to which the MD5 checksum is applied. Also see RFC
3562 which discusses the security requirements of this keying material.
||Limit the amount of information available through looking
glasses and DNS resource records, being careful not to expose TCP port
The IETF ingress filtering standard is defined in RFC
2827. A discussion of egress filtering can be found at http://www.sans.org/y2k/egress.htm.
The use of the TCP MD5 Signature Option will prevent the exploitation of this
vulnerability. Router customers should implement this on all BGP peering points
if it is supported by the router, upgrading the router firmware if necessary.
Please refer to the Vendor Information section of this advisory for implementation
Some vendors will have reduced the likelihood of successful denial of service
by amending the TCP implementation to issue a further acknowledgment packet
challenge for RST and SYN packets that do not have exactly the expected sequence
The Internet Engineering Task Force (IETF)
has published an Internet Draft to co-incide with the release of this advisory. The
text of this draft is available from the IETF web site:
NISCC has produced best practice guidelines for BGP available at
Secure configuration templates for BGP implementations on Cisco IOS and Juniper
JunOS can be found at:
Guidance on tuning of the IP stack for a number of different UNIX operating
systems is available at http://www.cymru.com/Documents/ip-stack-tuning.html
The following vendors have provided information about how their products are
affected by these vulnerabilities.
Please note that JPCERT/CC have
released a Japanese language advisory for this vulnerability which contains
additional information regarding Japanese vendors. This advisory is available
|| Certicom's SSL software developer toolkits
(SDK), requires a transport mechanism, however it is not restricted to
TCP. The default implementation that is shipped with the product utilizes
the supported operating system's TCP/IP stack. Certicom recognizes that
the indicated vulnerability is against the protocol stack itself and not
directly the application on top. As our products (SSL Plus, SSL Plus for
Java, Security Builder SSL-C, and Security Builder SSL-J), are primarily
used in a web server environment, a denial of service attack is important
to us and our customers. As there is no patch or workaround that Certicom
can implement within our products, we feel that we are not directly vulnerable
to this advisory. Certicom's website is www.certicom.com.
latest release for VPN-1/FireWall-1 (R55 HFA-03) contains a protection
against this vulnerability. The
protection applies to both the firewall device and to hosts behind the
Please refer to the Check Point web site for further information at:
|| Place holder.
Inc. is vulnerable on their UNICOS, UNICOS/mk and UNICOS/mp systems. Spr's have been opened to track
this issue. Please contact your local Cray Service Representative
for more information.
|| Hitachi is investigating the potential
impact to Hitachi's products.
|| Not vulnerable.
Initiative Japan, Inc (IIJ)
will release a new firmware to fix this vulnerability. Details
are available on their web site at http://www.seil.jp/en/ann/announce_en_20040421_01.txt.
||=== NicheStack v2.0 TCP/IP ===
InterNiche Technologies has updated its NicheStack v2.0 TCP/IP product
to handle the scenarios described in NISCC Vulnerability Notice #236929. The
patch is available to all InterNiche customers in accordance with the terms
of their current support agreements.
More information can be found on www.iNiche.com or
=== NicheLite v2.0 TCP/IP ===
InterNiche Technologies has updated its NicheLite v2.0 TCP/IP product to
handle the scenarios described in NISCC Vulnerability Notice #236929. The
patch is available to all InterNiche customers in accordance with the terms
of their current support agreements.
More information can be found on www.iNiche.com or
|| Juniper Networks products are susceptible
to this vulnerability. Software is available that implements several mechanisms
to mitigate the associated risks. Customers should contact Juniper Networks
Technical Assistance Center for availability and download instructions.
Additional information is posted on our web site at https://www.juniper.net/support.
||NEC is aware of this vulnerability and
is trying to determine potential impacts on our products.
|| Polycom has investigated the potential
impact to our products for NISCC Advisory 236929.
Specific product information will be provided at http://www.polycom.com/securitycenter.
NISCC wishes to thank the following:
||Steve Bellovin, Rob Thomas and Paul Watson for their contributions
to this advisory.
||Cisco Systems Inc. and Juniper Networks Inc. for their help
with the content of this advisory and for their support during the disclosure
||JPCERT/CC for their assistance in co-ordinating this disclosure
The NISCC Vulnerability Management Team can be contacted as follows:
(Please quote the advisory reference in the subject line.)
|| +44 (0)20 7821 1330 Extension 4511
(Monday to Friday 08:30 - 17:00)
|| +44 (0)20 7821 1686
|| Vulnerability Management Team
PO Box 832
We encourage those who wish to communicate via email to make use of our PGP key.
This is available from http://www.uniras.gov.uk/UNIRAS.asc.
Please note that UK government protectively marked material should not be sent
to the email address above.
If you wish to be added to our email distribution list, please email your request
What is NISCC?
For further information regarding the UK National Infrastructure Security Co-Ordination
Centre, please visit the NISCC web site at:
Reference to any specific commercial product, process or service by trade name,
trademark manufacturer or otherwise, does not constitute or imply its endorsement,
recommendation, or favouring by NISCC. The views and opinions of authors expressed
within this notice shall not be used for advertising
or product endorsement purposes.
Neither shall NISCC accept responsibility for any errors or omissions contained
within this advisory. In particular, they shall not be liable for any loss or
damage whatsoever, arising from or in connection with the usage of information
contained within this notice.
© 2004 Crown Copyright
|| Initial release (1.0)
<End of NISCC Vulnerability Advisory>