Cisco Security Advisory

Cisco IOS Software TCP Denial of Service Vulnerability

High
Advisory ID:
cisco-sa-20100812-tcp
First Published:
2010 August 12 21:30 GMT
Version 1.1:
Final
Workarounds:
See below
Cisco Bug IDs:
CSCti18193
CVE-2010-2827
CVSS Score:
Base 7.8, Temporal 6.4Click Icon to Copy Verbose Score
AV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE-2010-2827

Summary

  • Cisco IOS® Software Release, 15.1(2)T is affected by a denial of service (DoS) vulnerability during the TCP establishment phase. The vulnerability could cause embryonic TCP connections to remain in a SYNRCVD or SYNSENT state. Enough embryonic TCP connections in these states could consume system resources and prevent an affected device from accepting or initiating new TCP connections, including any TCP-based remote management access to the device.

    No authentication is required to exploit this vulnerability. An attacker does not need to complete a three-way handshake to trigger this vulnerability; therefore, this vulnerability can be exploited using spoofed packets. This vulnerability may be triggered by normal network traffic.

    Cisco has released Cisco IOS Software Release 15.1(2)T0a to address this vulnerability.

    This advisory is posted at https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20100812-tcp.

Affected Products

  • This vulnerability affects only Cisco IOS Software Release 15.1(2)T. No other Cisco IOS Software Releases are affected. Cisco IOS XE Software, Cisco IOS XR Software, and Cisco NX-OS Software are not affected by this vulnerability.

    Vulnerable Products

    A Cisco device is vulnerable when it is running Cisco IOS Software Release 15.1(2)T. To determine the Cisco IOS Software Release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software Release name. Other Cisco devices do not have the show version command or may provide different output.

    The following example identifies a Cisco product that is running Cisco IOS Software Release 15.1(2)T with an installed image name of C2800NM-ENTSERVICES-M:

    Router#show version
Cisco IOS Software, 2800 Software (C2800NM-ENTSERVICES-M), Version 15.1(2)T, 
    RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright ©) 1986-2010 by Cisco Systems, Inc.
Compiled Mon 19-Jul-10 16:38 by prod_rel_team

<output truncated>

    Additional information about Cisco IOS Software Release naming conventions is available in the White Paper: Cisco IOS Reference Guide.

    Products Confirmed Not Vulnerable

    No other Cisco IOS Software versions are affected by this vulnerability.

    No other Cisco products are currently known to be affected by this vulnerability.

Details

  • TCP provides reliable data transmission services in packet-switched network environments. TCP corresponds to the transport layer (Layer 4) of the OSI reference model. Among the services TCP provides are stream data transfer, reliability, efficient flow control, full-duplex operation, and multiplexing.

    When TCP connections are terminated in Cisco IOS Software, they are allocated a transmission control block (TCB). All allocated TCBs, associated TCP port numbers, and the TCP state are displayed in the output of the show tcp brief all command-line interface (CLI) command.

    Cisco IOS Software version 15.1(2)T contains a vulnerability that could cause an embryonic TCP connection to remain in SYNRCVD or SYNSENT state without a further TCP state transition. Examining the output of the show tcp brief all command multiple times will indicate if TCP sessions remain in one of these states.

    This vulnerability is triggered only by TCP traffic that is terminated by or originated from the device. Transit traffic will not trigger this vulnerability.

    Both connections to and from the router could trigger this vulnerability. An example of a connection to the router is that you may still be able to ping the device, but fail to establish a TELNET or SSH connection to the device. For example, an administrator may still be able to ping the device but fail to establish a Telnet or SSH connection to the device. Administrators who attempt a Telnet or a SSH connection to a remote device from the CLI prompt will encounter a hung session and the "Trying <ip address|hostname> ..." prompt. The connection that is initiated or terminated by the router can be removed from the socket table by clearing the associated TCB with the clear tcp tcb 0x<address> command.

    Devices could be vulnerable if examining the output of the CLI command debug ip tcp transactions, displays the error messages connection queue limit reached: port <port number> or No wild listener: port <port number>.

    Devices could also be vulnerable if output from repetitive show tcp brief all CLI commands indicates many TCBs in the state SYNRCVD or SYNSENT.

    The following example shows a device that has several HTTP, SSH, and Telnet sessions in the TCP SYNRCVD state:

    Example#show tcp brief all
TCB       Local Address               Foreign Address             (state)
07C2D6C8  192.168.0.2.443             192.168.0.5.11660           SYNRCVD
07C38128  192.168.0.2.23              192.168.0.5.35018           SYNRCVD
07C2DD60  192.168.0.2.443             192.168.0.5.19316           SYNRCVD
07C2A8A0  192.168.0.2.80              192.168.0.5.13818           SYNRCVD

<output truncated>

    Any TCP sessions can be cleared by clearing the associated TCB with clear tcp tcb 0x<address> . Alternatively Administrators can clear all TCBs at once by issuing clear tcp tcb *.

    Note: This will clear all active and hung TCP connections.

    This vulnerability is documented in the Cisco bug ID CSCti18193 ( registered customers only) . This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-2827.

    Some TCP application specific information is provided in the following sections:

    Telnet and SSH

    Telnet can not be explicitly disabled on a Cisco IOS device. Configuring transport input none on the vty lines of a vulnerable device will prevent it from being exploited on TCP port 23. However, if the Cisco IOS SSH server feature is configured on the device, transport input none will not prevent the device from being exploited on TCP port 22.

    Configuration of vty access control lists can partially mitigate this vulnerability because the vulnerability can be exploited using spoofed IP source addresses.

    Border Gateway Protocol

    Routers that are configured with Border Gateway Protocol (BGP) can be protected further by using the Generalized Time to Live (TTL) Security Mechanism (GTSM) feature. GTSM allows users to configure the expected TTL of a packet between a source and destination address. Packets that fail the GTSM check will be dropped before TCP processing occurs, which prevents an attacker from exploiting this vulnerability through BGP. GTSM is implemented with the command ttl-security hops.

    Further information on protecting BGP can be found in Protecting Border Gateway Protocol for the Enterprise.

    TCP MD5 Authentication for BGP does not prevent this vulnerability from being exploited.

Workarounds

  • The only complete workaround to mitigate this vulnerability is to disable the specific features that make a device vulnerable, if this action is feasible.

    Allowing only legitimate devices to connect to affected devices will help limit exposure to this vulnerability. Refer to the following Control Plane Policing and Configuring Infrastructure Access Lists subsections for further details. Because a TCP three-way handshake is not required, the mitigation must be combined with anti-spoofing measures on the network edge to increase effectiveness.

    Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link: https://sec.cloudapps.cisco.com/security/center/content/CiscoAppliedMitigationBulletin/cisco-amb-20100812-tcp .

    Cisco Guide to Harden Cisco IOS Devices

    The Cisco Guide to Harden Cisco IOS Devices provides examples of many useful techniques to mitigate TCP state manipulation vulnerabilities. These include:

    • Infrastructure Access Control Lists (iACL)
    • Receive Access Control Lists (rACL)
    • Transit Access Control Lists (tACL)
    • vty Access Control Lists
    • Control Plane Policing (CoPP)
    • Control Plane Protection (CPPr)

    For more information on these topics, consult Cisco Guide to Harden Cisco IOS Devices.

    CoPP

    For devices that need to offer TCP services, administrators can use CoPP to block TCP traffic from untrusted sources that is destined to the affected device. Cisco IOS Software Releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP may be configured on a device to protect the management and control planes and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to specific network configurations:

    
!
!-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted.
!-- Everything else is not trusted. The following access list is used
!-- to determine what traffic needs to be dropped by a control plane
!-- policy (the CoPP feature.) If the access list matches (permit),
!-- then traffic will be dropped. If the access list does not
!-- match (deny), then traffic will be processed by the router.
!-- Note that TCP ports 22 and 23 are examples; this 
!-- configuration needs to be expanded to include all used
!-- TCP ports.
!


access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 22
access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 23
access-list 100 deny tcp host 172.16.1.1 any eq 22
access-list 100 deny tcp host 172.16.1.1 any eq 23
access-list 100 permit tcp any any



!
!-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4
!-- traffic in accordance with existing security policies and
!-- configurations for traffic that is authorized to be sent
!-- to infrastructure devices.
!-- Create a class map for traffic that will be policed by
!-- the CoPP feature.
!


class-map match-all drop-tcp-class
  match access-group 100



!
!-- Create a policy map that will be applied to the
!-- Control Plane of the device, and add the "drop-tcp-traffic"
!-- class map.
!


policy-map control-plane-policy
 class drop-tcp-class
  drop



!
!-- Apply the policy map to the control plane of the
!-- device.
!



control-plane
 service-policy input control-plane-policy

    warning Warning: Because a TCP three-way handshake is not required to exploit this vulnerability, it is possible to spoof the IP address of the sender, which could defeat access control lists (ACLs) that permit communication to these ports from trusted IP addresses.

    In the preceding CoPP example, the access control entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Additional information on the configuration and use of the CoPP feature can be found at Control Plane Policing Implementation Best Practices and Control Plane Policing.

    Configuring iACLs

    Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of your network. Infrastructure ACLs are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The white paper Protecting Your Core: Infrastructure Protection Access Control Lists presents guidelines and recommended deployment techniques for infrastructure protection ACLs.

    BGP Considerations

    GTSM can help prevent exploitation of this vulnerability by means of the BGP port because packets that originate from devices that do not pass the TTL check configured by GTSM are dropped before any TCP processing occurs. For information on GTSM refer to BGP Support for TTL Security Check and BGP Time To Live Security Check.

    Embedded Event Manager (EEM)

    A Cisco IOS Embedded Event Manager (EEM) policy that is based on Tool Command Language (Tcl) can be used on vulnerable Cisco IOS devices to identify and detect a hung, extended, or indefinite TCP connection that is caused by this vulnerability. The policy allows administrators to monitor TCP connections on a Cisco IOS device. When Cisco IOS EEM detects potential exploitation of this vulnerability, the policy can trigger a response by sending a syslog message or a Simple Network Management Protocol (SNMP) trap to clear the TCP connection. The example policy provided in this document is based on a Tcl script that monitors and parses the output from two commands at defined intervals, produces a syslog message when the monitor threshold reaches its configured value, and can reset the TCP connection.

    The Tcl script is available for download at the Cisco Beyond: Embedded Event Manager (EEM) Scripting Community at the following link http://forums.cisco.com/eforum/servlet/EEM?page=eem&fn=script&scriptId=2041, and the device sample configuration is provided below.

    
!
!-- Location where the Tcl script will be stored
!


event manager directory user policy disk0:/eem


!
!-- Define variable and set the monitoring interval
!-- as an integer (expressed in seconds)
!


event manager environment EEM_MONITOR_INTERVAL 60


!
!-- Define variable and set the threshold value as
!-- an integer for the number of retransmissions
!-- that determine if the TCP connection is hung
!-- (a recommended value to use is 15)
!


event manager environment EEM_MONITOR_THRESHOLD 15


!
!-- Define variable and set the value to "yes" to
!-- enable the clearing of hung TCP connections
!


event manager environment EEM_MONITOR_CLEAR yes


!
!-- Define variable and set to the TCP connection
!-- state or states that script will monitor, which
!-- can be a single state or a space-separated list
!-- of states
!


event manager environment EEM_MONITOR_STATES SYNRCVD SYNSENT


!
!-- Register the script as a Cisco EEM policy
!


event manager policy monitor-sockets.tcl


!

Fixed Software

  • When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution.

    In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance.

    Each row of the Cisco IOS Software table (below) names a Cisco IOS release train. If a release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table.

    Major Release

    Availability of Repaired Releases

    Affected 12.x-Based Releases

    First Fixed Release

    12.0 - 12.4

    12.0 through 12.4 based releases are not affected

    Affected 15.0-Based Releases

    First Fixed Release

    15.0

    There are no affected 15.0 based releases

    Affected 15.1-Based Releases

    First Fixed Release

    15.1T

    15.1(2)T0a

    15.1(2)T1; available on 20-AUG-2010

    Releases prior to 15.1(2)T are not vulnerable. The vulnerability is first fixed in release 15.1(2)T0a.

Exploitation and Public Announcements

  • The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory.

    This vulnerability was reported to Cisco by a customer.

Cisco Security Vulnerability Policy

  • To learn about Cisco security vulnerability disclosure policies and publications, see the Security Vulnerability Policy. This document also contains instructions for obtaining fixed software and receiving security vulnerability information from Cisco.

Subscribe to Cisco Security Notifications

Related to This Advisory

URL

Revision History

  • Revision 1.0

    2010-August-12

    Initial public release.

    Show Less

Cisco Security Vulnerability Policy

  • To learn about Cisco security vulnerability disclosure policies and publications, see the Security Vulnerability Policy. This document also contains instructions for obtaining fixed software and receiving security vulnerability information from Cisco.

Subscribe to Cisco Security Notifications

Related to This Advisory