[NEWS] Vulnerability in the TCP Protocol Allows RST Spoofing (Cisco Advisory)

From: SecuriTeam (support_at_securiteam.com)
Date: 04/22/04

  • Next message: SecuriTeam: "[UNIX] CVS Server and Client Vulnerabilities (CVSROOT)"
    To: list@securiteam.com
    Date: 22 Apr 2004 18:48:30 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.

    - - - - - - - - -

      Vulnerability in the TCP Protocol Allows RST Spoofing (Cisco Advisory)


    A vulnerability in the Transmission Control Protocol (TCP) specification
    (RFC793) has been discovered. The successful exploitation enables an
    adversary to reset any established TCP connection in a much shorter time
    than was previously discussed publicly.


    Vulnerable Systems:
     * All Cisco products which contain a TCP stack are susceptible to this
     * A full list can be found at the original advisories linked below.

    Immune Systems:
     * Cisco VPN 3000 Series Concentrators
     * Cisco Firewall Services Module for Cisco Catalyst 6500 Series and Cisco
    7600 Series (FWSM)

    Depending on the application, the connection may get automatically
    re-established. In other cases, a user will have to repeat the action (for
    example, open a new Telnet or SSH session). Depending upon the attacked
    protocol, a successful attack may have additional consequences beyond
    terminated connection that must be considered. This attack vector is only
    applicable to the sessions that are terminating on a device (such as a
    router, switch, or computer), and not to the sessions that are only
    passing through the device (for example, transit traffic that is being
    routed by a router). In addition, the attack vector does not directly
    compromise data integrity or confidentiality.

    TCP is the transport layer protocol designed to provide
    connection-oriented reliable delivery of a data stream. To accomplish
    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 packet with the
    reset (RST) flag set because a reset does not expect a packet in return.
    The full specification of the TCP protocol can be found at
    <http://www.ietf.org/rfc/rfc0793.txt> http://www.ietf.org/rfc/rfc0793.txt
    According to the RFC793 specification, it is possible to reset an
    established TCP connection by sending a packet with the RST or synchronize
    (SYN) flag set. In order for this to occur, the 4-tuple must be known or
    guessed (source and destination IP address and ports) together with a
    sequence number. However, the sequence number does not have to be an exact
    match; it is sufficient to fall within the advertised window. This
    significantly decreases the effort required by an adversary: The larger
    the window, the easier it is to reset the connection. While source and
    destination IP addresses may be relatively easy to determine, the source
    TCP port must be guessed. The destination TCP port is usually known for
    all standard services (for example, 23 for Telnet, 80 for HTTP). Many
    operating systems (OSs) use predictable ephemeral ports for known services
    with a predictable increment (the next port which will be used for a
    subsequent connection). These values, while con! stant for a particular OS
    and protocol, do vary from one OS release to another.

    Here is an example of a normal termination of a TCP session:

    Host(1) Host(2)
    | |
    | |
    | ACK ack=1001, window=5000 |
    | |

    Host(1) is closing the session

    | RST seq=1001 |
    | |
    Host(2) is closing the session

    In addition, the following scenario is also permitted:

    Host(1) Host(2)
    | |
    | |
    | ACK ack=1001, window=5000 |
    | |

    Host(1) is closing the session

    | RST seq=4321 |
    | |

    Host(2) is closing the session

    Note how the RST packet was able to terminate the session although the
    sequence number was not the next expected one (which is 1001). It was
    sufficient for the sequence number to fall within the advertised "window".
    In this example, Host(2) was accepting sequence numbers from 1001 to 6001
    and 4321 is clearly within the acceptable range.

    As a general rule, all protocols where a TCP connection stays established
    for longer than one minute should be considered exposed.

    The impact is different for each specific protocol. While, in the majority
    of cases, a TCP connection will be automatically re-established, in some
    specific protocols a second order of consequences may have a larger impact
    than tearing down the connection itself. The Cisco PSIRT has analyzed
    multiple TCP-based protocols, as they are used within our offering, and we
    believe that this vulnerability does not have a significant impact on
    them. We will present our analysis for a few protocols that have the
    potential for higher impact due to the long-lived connections.

    Voice signaling H.225, H.245 (part of H.323 suite):
    H.225 and H.245 protocols are used in voice signaling. Their purpose is to
    negotiate parameters for content transfer (voice or video). The
    established sessions persist for the duration of a call. Any call in
    progress is terminated when the signaling session is broken. A new
    signaling session will be established immediately for the new call, but
    terminated calls cannot be re-established.

    Each call from an IP telephone or softphone will result in the creation of
    a single signaling session. Terminating that signaling session affects
    only a single user. It is possible that a single signaling session is
    responsible for multiple calls, but that setup is used deeper within the
    Service Provider's network. Determining all necessary parameters for
    mounting an attack is deemed a non-trivial task if the network is designed
    according to the current best practices.

    Network Storage (iSCSI, FCIP):
    Network Storage products use two TCP-based protocols: SCSI over IP (iSCSI)
    and Fiber Channel over IP (FCIP).

     * SCSI over IP (iSCSI)
    iSCSI is used in a client/server environment. The client is your computer
    and it is only the client that initiates a connection. This connection is
    not shared with any other users. A separate session is established for
    each virtual device used. Terminating the session will not have any
    adverse consequences if people are using current drivers from Microsoft
    for Windows and from Cisco for Linux. These drivers will re-establish the
    session and continue transfer from the point where it was disconnected.
    Drivers from other vendors may behave differently.
    The user may notice that access to a virtual device is slightly slower
    than usual.
     * Fiber Channel over IP (FCIP)
    FCIP is a peer-to-peer protocol. It is used for mirroring data between
    switches. Each peer can initiate the session. Switches can, and should be
    in practice, configured in a mesh. Bringing one link down will cause
    traffic to be re-routed over other link(s). If an adversary can manage to
    terminate the session multiple times in a row, the user's application may
    terminate with a "Device unreachable" or similar error message. This does
    not have any influence on the switch itself and the user can retry the
    The user may notice that access to a virtual device is slightly slower
    than usual. An occasional error message is possible.
    Transport Layer Security/Secure Socket Layer (TLS/SSL)
    Since this vulnerability operates on a TCP layer, encryption does not
    provide any protection. SSL/TLS connections can be used to encapsulate
    various kinds of traffic and these sessions can be long lived. A
    successful exploitation does not impact confidentiality of the data. An
    encrypted session can be attacked either on the originating or terminating
    host or on the firewalls in front of them (if they exist).

    The effectiveness of any workaround is dependent on specific customer
    situations such as product mix, network topology, traffic behavior, and
    organizational mission. Due to the variety of affected products and
    releases, customers should consult with their service provider or support
    organization to ensure any applied workaround is the most appropriate for
    use in the intended network before it is deployed.

    There are no workarounds available to mitigate the effects of this

    It is possible to mitigate the exposure on this vulnerability by applying
    anti-spoofing measures on the edge of the network.

    By enabling Unicast Reverse Path Forwarding (uRPF), all spoofed packets
    will be dropped at the first device. To enable uRPF, use the following
    router(config)#ip cef
    router(config)#ip verify unicast reverse-path

    Please consult
    <http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7d4.html> http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7d4.html and <ftp://ftp-eng.cisco.com/cons/isp/security/URPF-ISP.pdf> ftp://ftp-eng.cisco.com/cons/isp/security/URPF-ISP.pdf for further descriptions of how uRPF works and how to configure it in various scenarios. This is especially important if you are using asymmetric routing.

    Access control lists (ACLs) should also be deployed as close to the edge
    as possible. Unlike uRPF, you must specify the exact IP range that is
    permitted. Specifying which addresses should be blocked is not the optimal
    solution because it tends to be harder to maintain.

    Caution: In order for anti-spoofing measures to be effective, they must be
    deployed at least one hop away from the devices which are being protected.
    Ideally, they will be deployed at the network edge.

    Install vendor patch. List of available software fixes is available at the
    full advisory linked below.

    Exploitation and Public Announcements:
    The Cisco PSIRT is not aware of any public announcements or malicious use
    of the vulnerability described in this advisory.

    The exploitation of the vulnerability with packets having RST flag set
    (reset packets) was discovered by Paul (Tony) Watson of OSVDB.org. The
    extension of the attack vector to packets with SYN flag set and the
    vendors cooperating on the resolution of this issue discovered data


    The information has been provided by <mailto:psirt@cisco.com> Cisco
    Systems Product Security Incident Response Team.

    The original article can be found at:



    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com


    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[UNIX] CVS Server and Client Vulnerabilities (CVSROOT)"

    Relevant Pages

    • Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime
      ... TCP resources are not held for two hours. ... connection, makes the request, receives the reply, and then closes the TCP ... HTTP 1.1, on the other hand, uses HTTP keep-alives by default. ... App session state controls application-side sessions created using ASP, PHP, ...
    • Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime
      ... the session is never fully ... > TCP resources are not held for two hours. ... > connection, makes the request, receives the reply, and then closes the TCP ... HTTP 1.1, on the other hand, uses HTTP keep-alives by ...
    • Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime
      ... For instance the TCP resources would be held ... for 2 hours while the http connection resources would ... Session State was something else too. ...
    • Re: APPN Connection z/os - AHHC / LLC2.
      ... implied that you session stopped for a while and then continued. ... the ANNC link is a type 2.1 connection. ... I would suggest trying to limit the request unit size used over the type 2.1 ... MAXDATA operand when defining a PU statement for an adjacent link station ...
    • Re: Remote desktop deadlock on XP SP2
      ... the TS connection is frozen, even if I specify a wait timeout. ... TermSrv.dll creates a new session for the purpose of displaying the logon ... lives on a DPC routine for the network miniport ... the network packets are encapsulated and decapsulated in UDP. ...