Vulnerability Issues in TCP

 From: UNIRAS (HM Govt CERT (HD)) [uniras@niscc.gov.uk] Sent: 20 April 2004 16:58 To: 'uniras@niscc.gov.uk' Cc: 'interim-alerts@lists.niscc.gov.uk'; 'interim@lists.niscc.gov.uk' Subject: UNIRAS ALERT - 17/04 - NISCC Vulnerability Advisory 236929 - Vulnerability Issues in TCP   - ----------------------------------------------------------------------------------       UNIRAS (UK Govt CERT) ALERT - 17/04 dated 20.04.04  Time: 17:00    UNIRAS is part of NISCC (National Infrastructure Security Co-ordination Centre) - ----------------------------------------------------------------------------------    UNIRAS material is also available from its website at www.uniras.gov.uk and          Information about NISCC is available from www.niscc.gov.uk - ----------------------------------------------------------------------------------  Title =====  NISCC Vulnerability Advisory 236929 - Vulnerability Issues in TCP   Detail ======     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/2^32 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/2^32 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:    [Please note that updates to this advisory will not be notified by email.]  This vulnerability has been assigned the CVE name CAN-2004-0230.  [http://cve.mitre.org/cgi-bin/cvename.cgi?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 https://www.sans.org/white-papers/.  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: https://www.ietf.org/archive/id/draft-ietf-tcpm-tcpsecure-00.txt  NISCC has produced best practice guidelines for BGP available at   Filtering Guide.pdf  Secure configuration templates for BGP implementations on Cisco IOS and Juniper  JunOS can be found at:    *  Cisco    https://www.team-cymru.com/      *  Juniper      Guidance on tuning of the IP stack for a number of different UNIX operating systems  is available at https://www.cymru.com/Documents/ip-stack-tuning.html    Vendor Information  - ------------------ A list of vendors affected by this vulnerability is available from the web site at     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.    References - ----------    Internet Engineering Task Force     - RFC 793  Transmission Control Protocol       https://www.ietf.org/rfc/rfc793.txt     - RFC 1323 TCP Extensions for High Performance       https://www.ietf.org/rfc/rfc1323.txt     - RFC 1771 A Border Gateway Protocol 4 (BGP-4)       https://www.ietf.org/rfc/rfc1771.txt     - RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option       https://www.ietf.org/rfc/rfc2385.txt     - RFC 2827 Network Ingress Filtering       https://www.ietf.org/rfc/rfc2827.txt     - RFC 3562 Considerations for the TCP MD5 Signature Option       https://www.ietf.org/rfc/rfc3562.txt     - Internet Draft - Secure TCP       https://www.ietf.org/archive/id/draft-ietf-tcpm-tcpsecure-00.txt     NISCC     - Web site version of this advisory including vendor impact statements            - Best Practice Guidelines - Border Gateway Protocol        Filtering Guide.pdf      Configuration and Tuning Guides     - Secure BGP Template for Cisco IOS       https://www.team-cymru.com/     - JUNOS Secure BGP Template            - UNIX IP Stack Tuning Guide       https://www.cymru.com/Documents/ip-stack-tuning.html     Other Documents     - SANS discussion on egress filtering       https://www.sans.org/white-papers/     Vulnerability Databases       - Common Vulnerabilities and Exposures (CVE)       http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0230     - Open Source Vulnerability Database (OSVDB)          Contact Information - ------------------- The NISCC Vulnerability Management Team can be contacted as follows:  Email	   vulteam@niscc.gov.uk             Please quote the advisory reference in the subject line  Telephone  +44 (0) 20 7821 1330 Ext 4511            Monday - 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    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 .   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    - ----------------------------------------------------------------------------------  For additional information or assistance, please contact the HELP Desk by  telephone or Not Protectively Marked information may be sent via  EMail to: uniras@niscc.gov.uk  Office Hours: Mon - Fri: 08:30 - 17:00 Hrs Tel: +44 (0) 20 7821 1330 Ext 4511 Fax: +44 (0) 20 7821 1686  Outside of Office Hours: On Call Duty Officer: Tel: +44 (0) 20 7821 1330 and follow the prompts  - ---------------------------------------------------------------------------------- UNIRAS wishes to acknowledge the contributions of NISCC for the information  contained in this Briefing.  - ---------------------------------------------------------------------------------- This Briefing contains the information released by the original author. Some  of the information may have changed since it was released. If the vulnerability  affects you, it may be prudent to retrieve the advisory from the canonical site  to ensure that you receive the most current information concerning that problem.  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 UNIRAS or NISCC.  The views  and opinions of authors expressed within this notice shall not be used for  advertising or product endorsement purposes.  Neither UNIRAS or NISCC shall also accept responsibility for any errors  or omissions contained within this briefing notice. 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.  UNIRAS is a member of the Forum of Incident Response and Security Teams (FIRST)  and has contacts with other international Incident Response Teams (IRTs) in  order to foster cooperation and coordination in incident prevention, to prompt  rapid reaction to incidents, and to promote information sharing amongst its  members and the community at large.  - ----------------------------------------------------------------------------------