Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Become a Partner and License Our Database or Notification Service
(Cisco Issues Advisory) Re: Many Simple Network Management Protocol (SNMP) Implementations Allow Remote Users to Deny Service or Obtain Access to the System
SecurityTracker Alert ID: 1003531|
SecurityTracker URL: http://securitytracker.com/id/1003531
(Links to External Site)
Date: Feb 13 2002
Denial of service via network, Execution of arbitrary code via network, Root access via network, User access via network|
Fix Available: Yes Vendor Confirmed: Yes |
CERT reported that the University of Oulu (Finland) has discovered vulnerabilities in many vendor implementations of the Simple Network Management Protocol (SNMP) version 1.|
The Oulu University Secure Programming Group (OUSPG, http://www.ee.oulu.fi/research/ouspg/) reports that there are numerous vulnerabilities in SNMPv1 implementations from many different vendors. A remote user can reportedly cause denial of service attacks.
Cisco confirms that there are multiple Cisco products that contain vulnerabilities in the processing of SNMP messages and that the vulnerabilities can be repeatedly exploited to produce a denial of service.
A long list of products is affected, including IOS and non-IOS based software versions. To see if your Cisco product and sofware version is affected, see the Cisco advisories:
A remote user may be able to cause denial of service conditions. Cisco reports that the vulnerability can be exploited to cause an affected Cisco product to crash and reload.|
Cisco has released fixes for some releases and is planning to release fixes for additional releases. To see if a fix is available or to see when a fix will be available for your product and software version, refer to the Cisco advisory at:|
Vendor URL: www.cisco.com/warp/public/707/cisco-malformed-snmp-msgs-pub.shtml (Links to External Site)
Access control error, Boundary error, Input validation error|
This archive entry is a follow-up to the message listed below.|
Source Message Contents
Date: Tue, 12 Feb 2002 20:13:51 -0500|
Subject: Cisco Security Advisory: Malformed SNMP Message-Handling Vulnerabilities
[Editor's Note: The following is a Cisco Advisory in text format. The advisory
has not been modified, per Cisco's requirements. To view the text tables, we
recommend viewing the original advisory, available at:
Cisco Security Advisory: Malformed SNMP Message-Handling Vulnerabilities
For Public Release 2002 February 12 20:00 GMT
Please provide your feedback on this document.
Multiple Cisco products contain vulnerabilities in the processing of Simple
Network Management Protocol (SNMP) messages. The vulnerabilities can be
repeatedly exploited to produce a denial of service. In most cases, workarounds
are available that may mitigate the impact. These vulnerabilities are identified
by various groups as VU#617947, VU#107186, OUSPG #0100, CAN-2002-0012, and
This advisory is available at
This security advisory applies to a broad range of Cisco products. To determine
if a product is vulnerable, review the list below. If software versions or
configuration information is included, then only those combinations are affected
(or unaffected). If the product or series is listed without any qualifying
software version information, then consult the Software Versions and Fixes
section to determine if the product is running an affected version of software.
Additional information per product is provided in the Details and Workarounds
The following Cisco products are vulnerable if they are running an affected
version of software:
800, 1000, 1005, 1400, 1600, 1700, 2500, 2600, 3600, MC3810, 4000, 4500, 4700,
6200, 6400 NRP, 6400 NSP series Cisco routers
ubr900 and ubr920 universal broadband routers
Catalyst 1500, 290x, 292x, 2900XL, 2948g, 2948g-l3, 2950, 3000, 3200, 3500XL,
3550, 4000, 4232, 4232-l3, 4840g, 4908g-l3, 4912g, 5000, 6000 RSFC series
AS5200, AS5300, AS5800 series access servers
Catalyst 6000 MSM, 6000 Hybrid Mode, 6000 Native Mode, 6000 Supervisor Module,
Catalyst ATM Blade, Catalyst 6000 Network Analysis Module (NAM)
RSM, 7000, 7010, 7100, 7200, ubr7200, 7500, 7600 OSR, 10000 ESR, and 12000 GSR
series Cisco routers
Lightstream 1010 ATM switches
Catalyst 8510CSR, 8510MSR, 8540CSR, 8540MSR series switches.
BPX, IGX, MGX WAN switches, and the Service Expansion Shelf
Cisco Secure PIX firewall
Cisco Secure Intrusion Detection System (NetRanger) appliance and IDS Module
BR340, WGB340, AP340, AP350, BR350 Cisco/Aironet wireless products
CSS11000 (Arrowpoint) Content Services Switch
Cache Engine 505 and 570 running 2.3 or 2.5
Content Engine 507, 560 and 590 running 2.3 or 2.5
Content Engine 507, 560, 590, and 7320 running 3.1, 4.0, or 4.1
VPN3000 (Altiga) VPN Concentrator
VPN5000 VPN Concentrator
Access Registrar running on Solaris 8
Cisco ws-x6608 and ws-x6624 IP Telephony Modules
Cisco Info Center
Hosting Solution Engine
User Registration Tool VLAN Policy Server
Cisco Element Management Framework
Products Not Affected
The following Cisco products are not affected by this vulnerability in the
specified configuration, either because they do not contain the associated
defect or because they do not support SNMP. If software version information is
provided, then only that specific combination of product and software version is
Catalyst 1900s switch running any version of CatOS
FastHub 300 Ethernet repeater
Cache Engine 505 and 570 running version 2.3 or 2.5.x
Cache Engine and Content Delivery Manager running CDM Enterprise 3.0.x
CR-4430B running CDM Enterprise 3.0.x
Device Fault Manager
IP Phone (all models)
SN5400 series storage routers
Access Registrar running on Solaris 7.5.1
No other Cisco product is known to be affected by this vulnerability.
Simple Network Management Protocol (SNMP) defines a standard mechanism for
remote management and monitoring of devices in an Internet Protocol (IP)
There are three types of SNMP messages: "get" requests to request information,
"set" requests which modify the configuration of the remote device, and "trap"
messages which provide a monitoring function.
An Object Identifier (OID) is the label employed by SNMP to uniquely specify an
item to be managed. OIDs in human-readable format are displayed as long strings
of decimal integers separated by periods, but they are packed into a more
efficient binary form for use within SNMP.
The largest group of vulnerabilities described in this advisory result from
insufficient checking of SNMP messages as they are received and processed by an
affected system. Malformed SNMP messages received by affected systems can cause
various parsing and processing functions to fail, resulting in a system crash
and a reload in most circumstances. Under some conditions, the affected device
can not reload. In a specific combination with an unrelated software defect, the
device reloads continuously and requires manual intervention to resume normal
These vulnerabilities can be easily and repeatedly demonstrated with the use of
the University of Oulu Secure Programming Group (OUSPG) "PROTOS" Test Suite for
SNMP. The test suite is generally used to analyze a protocol and produce
messages that probe various design limits within an implementation of a
protocol. Examples such as overly-long OIDs, malformed OIDs, and other
combinations of values appropriate to SNMP can be programmatically generated and
then transmitted to a network device under test. The test suite for SNMP, as
distributed, contains approximately 53,000 individual test cases. The authors
intend to make the SNMP test suite available to the public at the same time that
this advisory is published.
The vulnerability can be exploited to produce a Denial of Service (DoS) attack.
When the vulnerability is exploited, it can cause an affected Cisco product to
crash and reload.
SNMP messages are transported using User Datagram Protocol (UDP) and are subject
to IP source address spoofing. In any circumstance where ingress and egress
source IP address filtering is lacking, it is more likely that an attacker could
spoof the source IP address and circumvent access control mechanisms to cause a
vulnerable system to fail.
If an attacker is able to guess or otherwise obtain a read-only community string
for an affected device, then he or she could bypass SNMP access control relying
on the community string.
Software Versions and Fixes
Cisco IOS Software
Each row of the Cisco IOS software table (below) describes a release train and
the platforms or products for which it is intended. If a given release train is
vulnerable, then the earliest possible releases that contain the fix (the "First
Fixed Release") and the anticipated date of availability for each are listed in
the "Rebuild," "Interim," and "Maintenance" columns. 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. The release should be
upgraded at least to the indicated release or a later version (greater than or
equal to the First Fixed Release label). When selecting a release, keep in mind
the following definitions:
Most heavily tested, stable, and highly recommended release of a release
train in any given row of the table.
Constructed from the previous maintenance or major release in the same
train, it contains the fix for a specific defect. Although it receives less
testing, it contains only the minimal changes necessary to repair the
Built at regular intervals between maintenance releases and receives less
testing. Interims should be selected only if there is no other suitable
release that addresses the vulnerability. Interim images should be upgraded
to the next available maintenance release as soon as possible. Interim
releases are not available through manufacturing, and usually they are not
available for customer download from CCO without prior arrangement with the
In all cases, customers should exercise caution to confirm that the devices to
be upgraded contain sufficient memory and that current hardware and software
configurations will continue to be supported properly by the new software
release. If the information is not clear, contact the Cisco TAC for assistance
as shown in the "Obtaining Fixed Software" section.
More information on Cisco IOS software release names and abbreviations is
available at http://www.cisco.com/warp/public/620/1.html.
TrainImage Description or PlatformAvailability of Fixed Releases*
12.0(5)WC 2900XL-LRE 12.0(5)WC2b
12.0(5)XP, 2900XL, 3500XL platform 12.0(5)WC3
12.0(5)XU 2900XL, 3500XL platform 12.0(5)WC3
12.1(5)YI & 12.1(5)EY 12.1(5)YI1
2900XL/3500XL 12.0(5.1)XP 12.0(5)XU 12.0(5.2)XU 12.0(5.3)WC1 12.0(5)WC2
2900XL-LRE: 12.0(5)WC2, 12.0(5.4)WC1 12.0(5)WC2b
2950 12.0(5.3)WC1 12.0(5.4)WC1 12.0(5)WC2 12.1(6)EA2 12.1(6)EA2a
3550 12.1(4)EA1e 12.1(6)EA1 12.1(6)EA1a 12.1(8)EA1b
Please review the information in the following link for details on Cisco non-IOS
Obtaining Fixed Software
Cisco is offering free software upgrades to remedy this vulnerability for all
affected customers. Customers with service contracts may upgrade to any software
release containing the feature sets they have purchased. Customers without
contracts may upgrade only within a single row of the table above, except that
any available fixed software release will be provided to any customer who can
use it and for whom the standard fixed software release is not yet available.
Customers may only install and expect support for the feature sets they have
Customers with contracts should obtain upgraded software through their regular
update channels. For most customers, this means that upgrades should be obtained
through the Software Center on Cisco's Worldwide Web site at
Customers whose Cisco products are provided or maintained through prior or
existing agreement with third-party support organizations such as Cisco
Partners, authorized resellers, or service providers should contact that support
organization for assistance with the upgrade, which should be free of charge.
Customers who purchased directly from Cisco but who do not hold a Cisco service
contract, and customers who purchase through third party vendors but are
unsuccessful at obtaining fixed software through their point of sale, should
obtain fixed software by contacting the Cisco Technical Assistance Center (TAC).
TAC contacts are as follows:
+1 800 553 2447 (toll free from within North America)
+1 408 526 7209 (toll call from anywhere in the world)
See http://www.cisco.com/warp/public/687/Directory.shtml for additional TAC
contact information, including instructions and e-mail addresses for use in
Please have your product serial number available and give the URL of this notice
as evidence of your entitlement to a free upgrade. Free upgrades for
non-contract customers must be requested through the TAC.
Please do not contact either "email@example.com" or "firstname.lastname@example.org" for
The usefulness of any workaround is dependent on specific customer situations
such as products, software versions, network topology, traffic behavior, and
organizational mission. Due to the great variety of affected products and
releases, customers should carefully evaluate each workaround to ensure it is
appropriate for use in the intended network before it is deployed.
Turn SNMP off in the device. This is an effective workaround, but removes
management capability to the device. This can be done using the following
Removing the community string public with the configure command:
no snmp-server community public ro
is not sufficient as the SNMP server will still be running and the device will
be vulnerable. The command no snmp server must be used instead. Verify SNMP
server status by using the enable command show snmp. You should see a response
of "%SNMP agent not enabled".
Apply an extended access list (ACL) to deny protocol UDP, port 161 and 162, at
the interface level such that SNMP access to the device is allowed only from
the network management workstations. This can be done using the following
access-list 100 permit ip host 188.8.131.52 any
access-list 100 deny udp any any eq snmp
access-list 100 deny udp any any eq snmptrap
access-list 100 permit any any
where 184.108.40.206 is the trusted network management station. This access list must
be applied to all interfaces using the following configure commands:
interface serial 0
ip access-group 100 in
This will not prevent spoofed IP packets with the source IP address set to
that of the network management station from reaching the switch's management
The access-list statement containing "snmptrap" will prevent notification
messages from entering the network when it is applied at the network edge.
The Cisco SAFE white papers cover techniques that can be used to control IP
address spoofing. These papers can be found at:
Cisco SAFE Solution
Two white papers cover securing your network in general and controlling IP
address spoofing specifically:
SAFE: A Security Blueprint for Enterprise Networks
SAFE: Extending the Security Blueprint to Small, Midsize, and Remote-User
Workarounds with Caveats
Apply an SNMP community-based ACL to allow SNMP access to the device only from
the network management workstations using the following configure commands:
access-list 1 permit 220.127.116.11
snmp-server community string1 ro 1
In this case the trusted management station is at address 18.104.22.168.
If community strings are also configured for notifications, they must be
different than the community strings used for requests in order for this
workaround to be effective. Use the following configure commands to change
community strings for notifications that are the same as community strings
used for requests.
no snmp-server host 22.214.171.124 string1
snmp-server community string1 ro 1
The second command above reapplies the access list to the community and must
be reentered after the snmp-server host command is entered to ensure the
access list is applied correctly in some Cisco IOS software releases.
Use the following configure command to tell the device to send notifications
using the new community string:
snmp-server host 126.96.36.199 anythingbutstring1
All community strings used for notifications, like the "anythingbutstring1"
community string above, need to be set to deny all SNMP requests. Use the
following configure commands to do this:
access-list 2 deny any
snmp-server community anythingbutstring1 ro 2
This is required because Cisco IOS software configures community strings used
for notifications with no read or write view. You cannot see or change any
information on the device using this string. However, requests using a
community string with no view will still be processed by the device and the
PROTOS tool could exploit this processing and crash the device.
Please note that in order for this to take effect, the commands must be issued
in the following order:
snmp-server host 188.8.131.52 anythingbutstring1
snmp-server community anythingbutstring1 ro 2
This configuration will not survive a reload.
In certain releases, entering the snmp-server community command will delete
the notify view required to send traps. This can be determined by running the
show snmp group
Look for two or more groups with the same name as the community string used
for notifications. The output should look like this:
groupname: anythingbutstring1 security model:v1
readview :v1default writeview:
row status: active access-list: 1
groupname: anythingbutstring1 security model:v2c
readview :v1default writeview:
row status: active access-list: 1
Ensure that the notifyview is set for the version of notifications you want
the device to send and that the access-list is set correctly for all security
If either fields are not correct, first reapply the configure command:
snmp-server host 184.108.40.206 anythingbutstring1
Then look at the output of show snmp group again. Take the view listed as the
notifyview, the correct access-list number, and the security model version and
enter the following configure command:
snmp-server group anythingbutstring1 v1 notify *tv.FFFFFFFF.FFFFFFFF access
Modify the above command to match your configuration. Verify this worked using
the show snmp group enable command.
Note: The snmp-server group command will show up in the configuration before
the snmp-server host command, so this part of the workaround will not survive
a reboot. After a reboot, the device will continue to send traps but the
snmp-server group command will need to be reentered to protect the device from
exploits using this community string.
Do not use the string "public" as a community string at all. The PROTOS test
suite uses "public" in its tests as configured by OULU.
Note: Even though the current version of the PROTOS tests will not crash the
Cisco IOS software device if the device community string is not public, it is
very easy to modify the PROTOS code so that other community string values are
used. Therefore, it is important to use a community ACL to further reduce your
The following workaround is effective in the following Cisco IOS software
11.0, 11.1, 11.2 and derivatives
12.0(3)T and later 12.0()T
12.0(6)S and later 12.0S
12.0(8.6)ST through 12.0(19.1)ST, 12.0(19.6)ST and later
12.1(1)T up to 12.1(4.4)T
12.1(1)E up to 12.1(9.4)E
12.1(1)EC up to 12.1(9.4)EC
to the best of our knowledge at this time based on testing and code inspection.
These workarounds are NOT effective in:
12.0(1)S through 12.0(5.x)S
12.0(19.3)ST, 12.0(19.3)ST1, 12.0(19.3)ST2
12.1(4.4)T2 and later 12.1()T
12.1(9.5)E and later 12.1()E
12.1(9.5)EC and later 12.1()EC
Troubleshooting Tips for Cisco IOS Software
Configure the startup-config with no SNMP and the running-config with the
SNMP. In the event of a successful exploit due to this vulnerability, the
affected device will reload with a new configuration in which SNMP is
disabled. This will prevent additional, repeated exploit of the vulnerability.
Configure the SNMP Community ACLs with the "log" keyword. Monitor syslog for
Periodically check SNMP for errors.
17005 SNMP packets input
37 Bad SNMP version errors **
15420 Unknown community name **
0 Illegal operation for community name supplied
1548 Encoding errors **
0 Number of requested variables
0 Number of altered variables
0 Get-request PDUs
0 Get-next PDUs
0 Set-request PDUs
0 SNMP packets output
0 Too big errors (Maximum packet size 1500)
0 No such name errors
0 Bad values errors
0 General errors
0 Response PDUs
0 Trap PDUs
Watch the counters marked **
Exploitation and Public Announcements
Cisco is not aware of any malicious exploitation of this vulnerability.
The largest set of these vulnerabilities were reported by the OUSPG at the
University of Oulu, Finland, in concert with the CERT Coordination Center. A
small number were reported by Cisco customers and some were internally
These vulnerabilities are present in other products not provided by Cisco, and
this security advisory is being published simultaneously with announcements from
the other affected organizations.
Status of This Notice: Interim
This is an interim Security Advisory notice. Cisco anticipates issuing updated
versions of this notice at irregular intervals as there are material changes in
the facts, and will continue to update this notice as necessary.
The reader is warned that this notice may contain inaccurate or incomplete
information. Although Cisco cannot guarantee the accuracy of all statements in
this notice, all of the facts have been checked to the best of our ability.
Cisco anticipates weekly updates of this notice until it reaches final status.
A standalone copy or paraphrase of the text of this Security Advisory that omits
the distribution URL in the following section is an uncontrolled copy, and may
lack important information or contain factual errors.
This notice will be posted on Cisco's Worldwide Web site at
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
email@example.com (includes CERT/CC)
Various internal Cisco mailing lists
Future updates of this notice, if any, will be placed on Cisco's Worldwide Web
server, but may or may not be actively announced on mailing lists or newsgroups.
Users concerned about this problem are encouraged to check the URL given above
for any updates.
Revision Number 1.02002-Feb-12 20:00 GMTInitial public release
Cisco Security Procedures
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 Web site at
http://www.cisco.com/warp/public/707/sec_incident_response.shtml. This includes
instructions for press inquiries regarding Cisco security notices. All Cisco
Security Advisories are available at http://www.cisco.com/go/psirt.
This notice is Copyright 2002 by Cisco Systems, Inc. This notice may be
redistributed freely after the release date given at the top of the text,
provided that redistributed copies are complete and unmodified, and include all
date and version information.
Go to the Top of This SecurityTracker Archive Page