Cisco Security Advisory

Advisory ID: cisco-sa-20100812-tcp

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20100812-tcp

Revision 1.1

For Public Release 2010 August 12 21:30  UTC (GMT)

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 http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20100812-tcp.

Affected Products

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.

Cisco has provided a score for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding CVSS at

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html.

Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at

http://intellishield.cisco.com/security/alertmanager/cvss.

Successful exploitation of this vulnerability may prevent some TCP applications on Cisco IOS Software from accepting any new connections. Exploitation could also prevent remote access to the affected system via the vtys. Remote access to the affected device via out-of-band connectivity to the console port should still be available.

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.

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: http://tools.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: 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


!

Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html , or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml .

Do not contact psirt@cisco.com or security-alert@cisco.com for software upgrades.

Customers with Service Contracts

Customers Using Third-Party Support Organizations

Customers Without Service Contracts

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.

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors.

This advisory is posted on Cisco's worldwide website at :

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20100812-tcp

In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients.

• cust-security-announce@cisco.com
  
• first-bulletins@lists.first.org
  
• bugtraq@securityfocus.com
  
• vulnwatch@vulnwatch.org
  
• cisco@spot.colorado.edu
  
• cisco-nsp@puck.nether.net
  
• full-disclosure@lists.grok.org.uk
  
• comp.dcom.sys.cisco@newsgate.cisco.com
  

Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates.

Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt.