 |
NISCC Vulnerability
Advisory 236929
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 793, the 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. Severity 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 information. 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 this vulnerability. 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 vulnerability. 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. Summary 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) flags set. 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 and TCP 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 of guessing an acceptable sequence number is much higher than 1/232 because the receiving TCP implementation will accept any sequence number in a certain range (or "window") of the expected sequence number. The window makes TCP reset attacks practicable. 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 service attacks. Details 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 an 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 incoming segments." 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 793, p31 states: "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:
As noted above BGP does
use long lived TCP connections, and the IP addresses and source port (and
destination
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.
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.
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.
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
Acknowledgements NISCC wishes to thank the following:
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 to uniras@niscc.gov.uk. What is NISCC? For further information regarding the UK National Infrastructure Security Co-Ordination Centre, please visit the NISCC web site at: http://www.niscc.gov.uk/aboutniscc/index.htm 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 Revision History
<End of NISCC Vulnerability Advisory> |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
