search menu icon-carat-right cmu-wordmark
Carnegie Mellon University

Software Engineering Institute

CERT Coordination Center

Cisco IOS fails to properly handle telnet connections

Vulnerability Note VU#384230

Original Release Date: 2004-08-27 | Last Revised: 2004-09-03

Overview

A denial-of-service vulnerability exists in Cisco's Internetwork Operating System (IOS). This vulnerability could allow remote attackers to prevent new connections to remote management services on a vulnerable device.

Description

Cisco IOS devices can be remotely managed using a number of protocols, including Secure Shell (ssh), Secure Copy (scp), Remote Shell (rsh), Telnet, Reverse Telnet, and the Hypertext Transfer Protocol (http). While telnet and reverse telnet are both used to manage devices remotely, the reverse telnet protocol provides the ability to telnet to a device and then subsequently connect to a third device using an asynchronous serial connection. Cisco IOS contains a vulnerability that allows specially crafted TCP packets sent to the telnet or reverse telnet service to cause the device to refuse subsequent connections to these management services.

There are reports of this vulnerability being actively exploited.

Impact

An unauthenticated, remote attacker with the ability to send TCP packets to ports used by the telnet (23/tcp) or reverse telnet (2001-2999/tcp, 3001-3099/tcp, 6001-6999/tcp, 7001-7099/tcp) service could cause a vulnerable device to refuse subsequent connections to the SSH, SCP, RSH, telnet, reverse telnet, and HTTP remote management services. Exploitation of this vulnerability could deny remote access to the device. Existing connections to these services are not affected.
Note: HTTP can be used to manage certain Cisco devices. Version 1.0 of the Cisco HTTP server, which is included in IOS versions prior to 12.2(15) is affected by this vulnerability. Version 1.1 of the Cisco HTTP server, which is included in IOS versions after and including 12.2(15) is not affected by this vulnerability.

In order to regain functionality, the problematic TCP connection must be cleared, or the device may need to be reloaded.

Solution

Until patches are available to address this issue, Cisco recommends the following workarounds to mitigate this vulnerability.


Workarounds
According to the Cisco Security Advisory, the following workarounds are recommended:

Enabling SSH and Disabling Telnet

Note: SSH support is only available in certain IOS feature sets and platforms.

Cisco devices that support SSH can enable it by following the steps listed here:


To disable telnet access to the device, configure the following on all your VTY lines:
    Router(config)# line vty 0 4
    Router(config-line)# transport input ssh

Note: Even if SSH is enabled, the IOS device is not protected until telnet access is disabled.

Configuring a VTY Access Class

It is possible to limit the exposure of the Cisco device by applying a VTY access class to permit only known, trusted devices to connect to the device via telnet, reverse telnet, RSH, SSH, or SCP.

For more information on restricting traffic to VTYs, please consult the following document:

Configuring Interface Access Lists (ACLs)

In addition to configuring a VTY access class, it may be desirable to block all telnet traffic from entering the network. The example below demonstrates how to block TCP port 23 and the reverse telnet traffic while permitting all other IP traffic:
    Router(config)# access-list 100 deny tcp any any eq telnet
    Router(config)# access-list 100 deny tcp any any range 2001 2999
    Router(config)# access-list 100 deny tcp any any range 3001 3099
    Router(config)# access-list 100 deny tcp any any range 6001 6999
    Router(config)# access-list 100 deny tcp any any range 7001 7099
    Router(config)# access-list 100 permit ip any any

The access list must then be configured to block inbound traffic on all public-facing interfaces:
    Router(config)# interface Ethernet 0/0
    Router(config-if)# ip access-group 100 in

Telnet should be blocked as part of a Transit ACL controlling all access to the trusted network. Transit 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 entitled "Transit Access Control Lists: Filtering at Your Edge" presents guidelines and recommended deployment techniques for transit ACLs:

Configuring Infrastructure Access Lists (iACLs)

Although it is often difficult to block traffic traversing your network, it is possible to identify traffic that should never be allowed to target your 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 entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection ACLs:

Configuring Receive Access Lists (rACLs)

For distributed platforms, rACLs may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the 12000 series GSR and 12.0(24)S for the 7500 series. The receive access lists protect the device from harmful traffic before the traffic can impact the route processor. Receive path 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 CPU load is distributed to the line card processors and helps mitigate load on the main route processor. The white paper entitled "GSR: Receive Access Control Lists" will help identify and allow legitimate traffic to your device and deny all unwanted packets:

Clearing TCP Connections Using the IOS CLI

The who command will show VTY connections to the device:

Router# who
   Line       User       Host(s)              Idle       Location
  0 con 0                192.168.10.72        00:00:00
* 2 vty 0                idle                 00:00:00 192.168.10.72
  3 vty 1                idle                 00:00:04 192.168.10.10

The above shows two connections on VTYs, one from 192.168.10.72, and one from 192.168.10.10. The * indicates which VTY belongs to the current session. In the above example, the user issuing the who command was connecting from 192.168.10.72. To clear the session from 192.168.10.10, which is on VTY 1, the following command is used:

Router# clear tcp line vty 1
[confirm]
[OK]

Note: If you are using telnet to connect to the device, accidentally clearing your TCP connection will disconnect your telnet session. If the IOS device has been exploited, it will not be possible to reconnect via telnet. Console access or a device reload will be required to restore service.

Vendor Information

384230
 
Expand all

Cisco Systems Inc. Affected

Updated:  August 27, 2004

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please refer to Cisco's Advisory "Cisco Telnet Denial of Service Vulnerability".

If you have feedback, comments, or additional information about this vulnerability, please send us email.


CVSS Metrics

Group Score Vector
Base
Temporal
Environmental

References

Acknowledgements

This vulnerability was reported by the Cisco Systems Product Security Incident Response Team (PSIRT).

This document was written by Damon Morda based on information provided by Cisco.

Other Information

CVE IDs: None
Severity Metric: 31.50
Date Public: 2004-08-27
Date First Published: 2004-08-27
Date Last Updated: 2004-09-03 14:49 UTC
Document Revision: 48

Sponsored by CISA.

Download PGP Key

Read CERT/CC Blog

Learn about Vulnerability Analysis