[GTER] CAIS-Alerta: Vulnerabilidade no protocolo TCP que afetam BGP

Liliana E. Velasquez Alegre Solha nina at cais.rnp.br
Tue Apr 20 17:33:32 -03 2004

---------- Forwarded message ----------
Date: Tue, 20 Apr 2004 17:26:20 -0300 (BRST)
From: Centro de Atendimento a Incidentes de Seguranca <cais at cais.rnp.br>
To: rnp-alerta at cais.rnp.br, rnp-seg at cais.rnp.br
Subject: CAIS-Alerta: Vulnerabilidade no protocolo TCP que afetam BGP


O CAIS esta' repassando o alerta divulgado pelo NISCC (National
Infrastructure Security Co-ordination Centre) intitulado "NISCC
Vulnerability Advisory 236929 Vulnerability Issues in TCP", que descreve
uma vulnerabilidade que afeta implementacoes do protocolo TCP
(Transmission Control Protocol) em concordancia com as RFCs 793
(Transmission Control Protocol) e 1323 (TCP Extensions for High

Se explorada, esta vulnerabilidade pode permitir que um atacante crie uma
condicao de Negacao de Servico (DoS) contra conexoes TCP existentes,
resultando no termino prematuro de sessoes e afetando a camada de

O protocolo BGP (Border Gateway Protocol) e' considerado potencialmente
como o mais afetado por esta vulnerabilidade por contar com sessoes TCP
persistentes entre os pares BGP. Vale lembrar que o BGP e' o principal
protocolo de roteamento utilizado na internet hoje em dia.

O impacto mais serio disso e' que qualquer sessao BGP pode ser remotamente
resetada causando flaps nas sessoes BGP e consequentemente DUMP nas rotas

Ainda de acordo com o alerta, ha tambem potencial de impacto em outros
protocolos de aplicacao, como DNS e SSL.

Sistemas afetados:

De acordo com o alerta, os seguintes fornecedores forneceram informacoes
sobre como seus produtos sao afetados por esta vulnerabilidade:

Os seguintes fornecedores disponibilizaram informacoes sobre como seus
produtos sao afetados por essa vulnerabilidade:

. Certicom

. Check Point

. Cisco

. Cray Inc.

. Hitachi

. Innovaphone

. Internet Initiative Japan, Inc

. InterNiche

. Juniper Networks


. Polycom

. Yamaha

Correcoes disponiveis:

No momento nao existem correcoes diponiveis, mas sim passos para se
mitigar o problema.

O CAIS recomenda que se procure informacoes diretamente com o fabricante
do produto em questao. Alem disso, o CAIS recomenda que os administradores
sigam as instrucoes para contornar o problema disponiveis no alerta do

Maiores informacoes:

. NISCC Vulnerability Advisory 236929 - Vulnerability Issues in TCP

. RFC 2385 - Protection of BGP Sessions via the TCP MD5 Signature Option


#       Rede Nacional de Ensino e Pesquisa (RNP)               #
#                                                              #
# cais at cais.rnp.br       http://www.cais.rnp.br                #
# Tel. 019-37873300      Fax. 019-37873301                     #
# Chave PGP disponivel   http://www.rnp.br/cais/cais-pgp.key   #

National Infrastructure Security Co-Ordination Centre
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


   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.


   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

   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

   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


   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

   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


   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.


   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:

   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

   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

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


       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:


       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 is investigating the potential impact to Hitachi's products.


       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


       === 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 at iNiche.com

       === 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 at iNiche.com

    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

       Additional information is posted on our web site at


       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




   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 in

   Contact Information

   The NISCC Vulnerability Management Team can be contacted as follows:

   | Email     | vulteam at niscc.gov.uk                             |
   |           | (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 at 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:

   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.

   (c) 2004 Crown Copyright

   Revision History

   April 20, 2004:   Initial release (1.0)

   <End of NISCC Vulnerability Advisory>
------------ Output from pgp ------------
Pretty Good Privacy(tm) Version 6.5.8
(c) 1999 Network Associates Inc.
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Export of this software may be restricted by the U.S. government.
File is signed.  Good signature from user "Centro de Atendimento a Incidentes de Seguranca <cais at cais.rnp.br>".
Signature made 2004/04/20 20:27 GMT

More information about the gter mailing list