NISCC Vulnerability Advisory 236929: Vulnerability Issues in TCP

[David Ahmad <da@xxxxxxxxxxxxxxxxx>]

http://www.uniras.gov.uk/vuls/2004/236929/index.htm

--

NISCC Vulnerability Advisory 236929

Vulnerability Issues in TCP


Version Information 

Advisory Reference 236929 
Release Date 20 April 2004 
Last Revision 20 April 2004 
Version Number 1.0 
 

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:

.  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 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.

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:

http://www.uniras.gov.uk/vuls/2004/236929/index.htm

[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.


Mitigation

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 information 
unnecessarily 


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.


Solution

Please refer to the Vendor Information section of this advisory for 
implementation specific remediation.

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 number.

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:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt

NISCC has produced best practice guidelines for BGP available at
http://www.niscc.gov.uk/BGP Filtering Guide.pdf

Secure configuration templates for BGP implementations on Cisco IOS and Juniper 
JunOS can be found at:

.  Cisco  http://www.cymru.com/Documents/secure-bgp-template.html  
.  Juniper  http://www.qorbit.net/documents/junos-bgp-template.pdf  


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 


Vendor Information 

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 at http://www.jpcert.or.jp/at/2004/at040003.txt.





Certicom Internet Initiative Japan, Inc   
Check Point InterNiche   
Cisco Juniper Networks   
Cray Inc NEC   
Hitachi Polycom   
Innovaphone Yamaha   




Certicom 
  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. 
Check Point 
  The 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 firewall.

Please refer to the Check Point web site for further information at:
http://www.checkpoint.com/techsupport/alerts/tcp_dos.html. 
Cisco 
  Place holder. 
Cray Inc 
  Cray 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 
  Hitachi is investigating the potential impact to Hitachi's products. 
Innovaphone 
  Not vulnerable. 
Internet Initiative Japan, Inc (IIJ) 
  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. 
InterNiche 
  === 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 through support@xxxxxxxxxx 


=== 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 through support@xxxxxxxxxx  
Juniper Networks 
  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 
  NEC is aware of this vulnerability and is trying to determine potential 
impacts on our products. 
Polycom 
  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. 
Yamaha 
  Pending. 


Acknowledgements

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 process. 
.  JPCERT/CC for their assistance in co-ordinating this disclosure in Japan. 


Contact Information

The NISCC Vulnerability Management Team can be contacted as follows:


Email vulteam@xxxxxxxxxxxx 
(Please quote the advisory reference in the subject line.) 
Telephone +44 (0)20 7821 1330 Extension 4511 
(Monday to Friday 08:30 - 17:00) 
Fax +44 (0)20 7821 1686 
Post Vulnerability Management Team
NISCC
PO Box 832
London
SW1P 1BG 

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@xxxxxxxxxxxxx


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

April 20, 2004:  Initial release (1.0) 
    

<End of NISCC Vulnerability Advisory>


-- 
David Mirza Ahmad
Symantec 

PGP: 0x26005712
8D 9A B1 33 82 3D B3 D0 40 EB  AB F0 1E 67 C6 1A 26 00 57 12