Posted on 02/12/2002 2:54:06 PM PST by oc-flyfish
Original release date: February 12, 2002 A complete revision history can be found at the end of this file. Products from a very wide variety of vendors may be affected. See Vendor Information for details from vendors who have provided feedback for this advisory. In addition to the vendors who provided feedback for this advisory, a list of vendors whom CERT/CC contacted regarding these problems is available from http://www.kb.cert.org/vuls/id/854306 Many other systems making use of SNMP may also be vulnerable but were not specifically tested. Numerous vulnerabilities have been reported in multiple vendors' SNMP implementations. These vulnerabilities may allow unauthorized privileged access, In addition to this advisory, we also have an FAQ available at The Simple Network Management Protocol (SNMP) is a widely deployed protocol that is commonly used to monitor and manage network devices. Version 1 of the protocol (SNMPv1) defines several types of SNMP messages that are used to request information or configuration changes, respond to requests, enumerate SNMP objects, and send unsolicited alerts. The OUSPG's research focused on the manner in which SNMPv1 agents and managers handle request and trap messages. By applying the PROTOS c06-snmpv1 test suite (http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/snmpv1/0100.html) to a variety of popular SNMPv1-enabled products, the OUSPG revealed the following vulnerabilities: VU#107186 - Multiple vulnerabilities in SNMPv1 trap handling SNMP trap messages are sent from agents to managers. A trap message may indicate a warning or error condition or otherwise notify the manager about the agent's state. SNMP managers must properly decode trap messages and process the resulting data. In testing, OUSPG found multiple vulnerabilities in the way many SNMP managers decode and process SNMP trap messages. VU#854306 - Multiple vulnerabilities in SNMPv1 request handling SNMP request messages are sent from managers to agents. Request messages might be issued to obtain information from an agent or to instruct the agent to configure the host device. SNMP agents must properly decode request messages and process the resulting data. In testing, OUSPG found multiple vulnerabilities in the way many SNMP agents decode and process SNMP request messages. Vulnerabilities in the decoding and subsequent processing of SNMP messages by both managers and agents may result in denial-of-service conditions, format string vulnerabilities, and buffer overflows. Some vulnerabilities do not require the SNMP message to use the correct SNMP community string. These vulnerabilities have been assigned the CVE identifiers CAN-2002-0012 and CAN-2002-0013, respectively. These vulnerabilities may cause denial-of-service conditions, service interruptions, and in some cases may allow an attacker to gain access to the affected device. Specific impacts will vary from product to product. Note that many of the mitigation steps recommended below may have significant impact on your everyday network operations and/or network architecture. Ensure that any changes made based on the following recommendations will not unacceptably affect your ongoing network operations capability. Appendix A contains information provided by vendors for this advisory. Please consult this appendix to determine if you need to contact your vendor directly. As a general rule, the CERT/CC recommends disabling any service or capability that is not explicitly required, including SNMP. Unfortunately, some of the affected products exhibited unexpected behavior or denial of service conditions when exposed to the OUSPG test suite even if SNMP was not enabled. In these cases, disabling SNMP should be used in conjunction with the filtering practices listed below to provide additional protection. As a temporary measure, it may be possible to limit the scope of these vulnerabilities by blocking access to SNMP services at the network perimeter. Ingress filtering manages the flow of traffic as it enters a network under your administrative control. Servers are typically the only machines that need to accept inbound traffic from the public Internet. In the network usage policy of many sites, there are few reasons for external hosts to initiate inbound traffic to machines that provide no public services. Thus, ingress filtering should be performed at the border to prohibit externally initiated inbound traffic to non-authorized services. For SNMP, ingress filtering of the following ports can prevent attackers outside of your network from impacting vulnerable devices in the local network that are not explicitly authorized to provide public SNMP services. snmp 161/udp # Simple Network Management Protocol (SNMP) The following services are less common, but may be used on some affected products snmp 161/tcp # Simple Network Management Protocol (SNMP)CERT® Advisory CA-2002-03 Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)
Last revised: February 12, 2002 (16:57 EST)
Source: CERT/CC
Systems Affected
http://www.kb.cert.org/vuls/id/107186Overview
I. Description
II. Impact
III. Solution
Apply a patch from your vendor
Disable the SNMP service
Ingress filtering
snmp 162/udp # SNMP system management messages
snmp 162/tcp # SNMP system management messages
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp # SNMP Unix Multiplexer
synoptics-relay 391/tcp # SynOptics SNMP Relay Port
synoptics-relay 391/udp # SynOptics SNMP Relay Port
agentx 705/tcp # AgentX
snmp-tcp-port 1993/tcp # cisco SNMP TCP port
snmp-tcp-port 1993/udp # cisco SNMP TCP port
As noted above, you should carefully consider the impact of blocking services that you may be using.
It is important to note that in many SNMP implementations, the SNMP daemon may bind to all IP interfaces on the device. This has important consequences when considering appropriate packet filtering measures required to protect an SNMP-enabled device. For example, even if a device disallows SNMP packets directed to the IP addresses of its normal network interfaces, it may still be possible to exploit these vulnerabilities on that device through the use of packets directed at the following IP addresses:
Careful consideration should be given to addresses of the types mentioned above by sites planning for packet filtering as part of their mitigation strategy for these vulnerabilities.
Finally, sites may wish to block access to the following RPC services related to SNMP (listed as name, program ID, alternate names)
snmp 100122 na.snmp snmp-cmc snmp-synoptics snmp-unisys snmp-utk
snmpv2 100138 na.snmpv2 # SNM Version 2.2.2
snmpXdmid 100249
Please note that this workaround may not protect vulnerable devices from internal attacks.
In many networks, only a limited number of network management systems need to originate SNMP request messages. Therefore, it may be possible to configure the SNMP agent systems (or the network devices in between the management and agent systems) to disallow request messages from non-authorized systems. This can reduce, but not wholly eliminate, the risk from internal attacks. However, it may have detrimental effects on network performance due to the increased load imposed by the filtering, so careful consideration is required before implementation. Similar caveats to the previous workaround regarding broadcast and loopback addresses apply.
Most SNMP-enabled products ship with default community strings of "public" for read-only access and "private" for read-write access. As with any known default access control mechanism, the CERT/CC recommends that network administrators change these community strings to something of their own choosing. However, even when community strings are changed from their defaults, they will still be passed in plaintext and are therefore subject to packet sniffing attacks. SNMPv3 offers additional capabilities to ensure authentication and privacy as described in RFC2574.
Because many of the vulnerabilities identified in this advisory occur before the community strings are evaluated, it is important to note that performing this step alone is not sufficient to mitigate the impact of these vulnerabilities. Nonetheless, it should be performed as part of good security practice.
In situations where blocking or disabling SNMP is not possible, exposure to these vulnerabilities may be limited by restricting all SNMP access to separate, isolated management networks that are not publicly accessible. Although this would ideally involve physically separate networks, that kind of separation is probably not feasible in most environments. Mechanisms such as virtual LANs (VLANs) may be used to help segregate traffic on the same physical network. Note that VLANs may not strictly prevent an attacker from exploiting these vulnerabilities, but they may make it more difficult to initiate the attacks.
Another option is for sites to restrict SNMP traffic to separate virtual private networks (VPNs), which employ cryptographically strong authentication.
Note that these solutions may require extensive changes to a site's network architecture.
Egress filtering manages the flow of traffic as it leaves a network under your administrative control. There is typically limited need for machines providing public services to initiate outbound traffic to the Internet. In the case of SNMP vulnerabilities, employing egress filtering on the ports listed above at your network border can prevent your network from being used as a source for attacks on other sites.
Disabling executable stacks (on systems where this is configurable) can reduce the risk of "stack smashing" attacks based on these vulnerabilities. Although this does not provide 100 percent protection against exploitation of these vulnerabilities, it makes the likelihood of a successful exploit much smaller. On many UNIX systems, executable stacks can be disabled by adding the following lines to /etc/system:
set noexec_user_stack = 1
set noexec_user_stack_log = 1
Note that this may go against the SPARC and Intel ABIs and can be bypassed as required in programs with mprotect(2). For the changes to take effect you will then need to reboot.
Other operating systems and architectures also support the disabling of executable stacks either through native configuration parameters or via third-party software. Consult your vendor(s) for additional information.
Because dealing with these vulnerabilities to systems and networks is so complex, the CERT/CC will provide a forum where administrators can share ideas and techniques that can be used to develop proper defenses. We have created an unmoderated mailing list for system and network administrators to discuss helpful techniques and tools.
You can subscribe to the mailing list by sending an email message to majordomo@cert.org. In the body of the message, type
subscribe snmp-forum
After you receive the confirmation message, follow the instructions in the message to complete the subscription process.
If you click on the link it will give you detailed info about the affected vendors and their steps to remedy the situation.
Out in the open, that's how to handle these things.
There was a thread with the news story but no technical data.
The story said that many companies already had patches out, while other companies didn't.
We need to commend the companies who are standing behind their product, and lean on the ones who haven't gotten a patch out.
If anyone's machine is vulnerable to this and there isn't a patch, post it and perhaps we can get some people to FReep the company demanding a patch.
"Most home users are not directly affected by these vulnerabilities. However, home users with more advanced configurations may be at risk. "
See their vendor list as oc-flyfish indicated in links in his #1 above.
-bw
I beg to differ -- Cert is wrong on this. The majority of cable and DSL modems have SNMP running so that the ISPs can manage them.
On another note, I was amazed that the Netopia router I use by default had SNMP setup. I have had it disabled since I installed it but it may still be vulnerable.
Anyone have info on the cable modems Cox installed back in 1997? I need to see if there is an update for it before everything goes to hell in a hand basket.
We should commend the tech companies who have already got a patch ready, and we should lean on the ones who have not.
Once again, MS is in the 'not' catagory.
Mr. Gates has a lot of 'turning' to do on that ship of his.
BTW: Can you add me to your tech list?
The Linux patches were out before the exploit was public knowledge. MS -- with literally billions in extra cash -- isn't yet ready.
Excuse me?
That is why we criticize MS -- and any 'poor' software company who treats security and quality problems as 'PR' problems.
But Mr. Gates has just begun. He'd better hit someone over the head for this. He should have made a point to beat everyone to the punch. They're going to have to start being first out with patches, if they want to sell this, "Trustworthy Computing" thing.
Assuming that *all* vendors received the info at the same time there really isn't an excuse for Microsoft.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.