This vulnerability could cause embryonic TCP connections to remain in a SYNRCVD or SYNSENT state.
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 ..." 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 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 or No wild listener: port . 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:
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.
Workaround:
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://www.cisco.com/warp/public/707/cisco-amb-20100812-tcp.shtml .
