Security Hole In SNMP

wiredog writes: "From ZDNET comes the news that there is apparently a serious security flaw in the Simple Network Management Protocol, used to control routers and other network devices." An anonymous reader points to the CERT advisory as well.

Comments

Not a SNMP hole

[Anonymous Coward]

This is a security hole in many implementations of SNMP, not in the protocol itself. This means that products can be patched without switching to a new protocol. Of course, SNMP devices will still be insecure if you don't change the default community strings (and even then, SNMPv1 sends the strings in plaintext).

Re:Not a SNMP hole

[Quill_28]

Actually this is first post that has made any sense. The problem in not with the SNMP protocol, but rather the software that implemented SNMP. This means the one hack(crack) will effect net-snmp but not MS's crappy agent and vice-versa. btw security problems with the SNMP protocol have been addressed in SNMPv3. Also, in most cases the only thing the crackers can do is shut the box down. I know DoS is a big deal, but taking over a router is bigger.

Re:Not a SNMP hole

[tqbf]

If this was a hole in an SMTP server it would make sense to say that it's specific to the server. Because the protocol in question in SNMP, it is NOT valid to make this assumption. Virtually all implementations of SNMP trace a lineage back to a common, ancient implementation.

The reason for this is that SNMP uses an incredibly complicated wire format: ASN.1/BER. ASN.1/BER is based on the (once seductive) idea that you could avoid interoperability and extensibility problems by (in effect) defining a programming language to encode and decode data structures. As long as you implement the primitives of the language, third parties can implement arbitrarily complex constructs on top of the protocol without changing your code.

The reality, of course, is that almost all queries fit into a tiny subset of the "language", and that the "language" itself is so complicated to implement (relative to other protocols) that nobody is willing to "reinvent the wheel".

So they all downoad the (free) CMU or UCD SNMP library and use that.

Hence, everyone is vulnerable.

Re:Not a SNMP hole

[tqbf]

Nobody uses SNMPv3.

Nobody uses SNMPv2

Everyone uses SNMPv1

People will ALWAYS use SNMPv1. Nobody will set up a new authentication infrastructure just for SNMP. They will build ad-hoc backchannels to isolate SNMP from the rest of the Internet. They will fail repeatedly, but it won't be nearly as expensive as deploying an entire new security infrastructure for network management.

This is the same reason why nobody will ever use DNSSEC, and why everyone uses SSH. SSH did the simplest thing possible and left the infrastructure up to the consumers. DNSSEC and SNMPvNG repeatedly fucked this simple problem up by trying to mandate more of the environment than was required to get off the ground.

From the so-never-mail-your-passwords dept?

[neoevans]

Who's in charge of Acronyms around here? It's not an SMTP problem!

End of email from SANS...

[heliocentric]

Turning off SNMP was one of the strong recommendations in the Top 20 Internet Security Threats that the FBI's NIPC and SANS and the Federal CIO Council issued on October 1, 2001. If you didn't take that action then, now might be a good time to correct the rest of the top 20 as well as the SNMP problem. The Top 20 document is posted at http://www.sans.org/top20.htm

Re:What is the flaw?

[kindbud]

Once again a security flaw is found, but nobody tells anyone what the security flaw is.

Bullshit:

http://www.kb.cert.org/vuls/id/107186
http://www.kb.cert.org/vuls/id/854306

These are linked to on the first page of the CERT Advisory. RTFA, doofus.

Wrong summation (again).

[hardaker]

The security flaw is not in the protocol, but rather in how people and companies have implemented it. Unfortunately, most people did in fact implement it in such a way that makes the products vulerable to crashing and /or buffer-overflow attacks. A good portion of the SNMP code to date is written based on early work from the cmu-snmp package, which was a reference release of the protocol. Hence, many of the companies and products that make use of that original code (including ucd-snmp and net-snmp, which I'm the lead developer for) are subject to the vulnerabilities as well. The ucd-snmp and net-snmp packages have been fixed as of a few months ago (and upgrading software is easy on linux, *bsd, etc boxes). However, people with flashroms containing software will have a much more challanging time getting updates from their vendors and installing them in a quick fashion if the deployment numbers of those types of boxes are large.

Re:Wrong summation (again).

[timothiy]

Screw you! I read it. I just didn't understand it. And what, you think that's going to stop me from posting a story? Like that's stopped me before.

No security in SNMPv1

[Simpler]

SNMP v1 as defined in RFC 1213 and RFC 1215 has no security features built in to begin with. You have to go to SNMP v2 or v3.

This means that if you like to configure yoru routers using SNMPv1 and someone intercepts your UDP packet, they can read the community string (normally used as an ad-hock password) you use and have access to your NE (network element).

This is a common security failure with a LOT of telecom equipment. Normally, if you enable SNMP on your boxes, keep the conguration port (normally found outside of service ports) inside a private LAN and hope for the best!

And the kicker is, I work for a telecom company implementing SNMP solutions on OOSes and EMSes. Even after 5 years or SNMPv2 being out (SNMPv3 has also come out in the last few years), most NE's being produced on the market (save for the big boys -- Nortel, Cisco, etc) come with standard SNMPv1 managment and configuration capabilities. Safe surfing.

Re:What is the flaw?

[Florian Weimer]

Obviously, you have never read such notes, otherwise you would now that CERT/CC never releases information which can be used to reproduce problems. They do point to the problems, but do not provide details. (Most of the time, you can guess the concrete problem, though.)

In fact, there are several different buffer overflow and format string bugs, in different SNMP implementations. The OUSPG report (which triggered this advisory) seems to be more detailed, but I still have to read it. (OTOH, SNMP vulnerabilities are rather boring stuff nowadays, any sane person blocks SNMP at the closest router.)

Those evil Microsoft d00ds

[Zico]

You'll notice that Microsofts response was to turn off the SNMP service until they get a patch ready.

Yeah, those bastards. Why can't they do things like the following model citizens?

• Red Hat: "Red Hat Inc. has investigated this vulnerablity, and currently has a candidate fix which is undergoing regression testing. Updated ucd-snmp packages incorporating this fix will be available shortly from this page shortly."
• Sun Microsystems: "Sun is currently generating patches for this issue and will be releasing a Sun Security Bulletin once the patches are available."
• Caldera: "A fix for supported versions of OpenServer 5 will be available at a later date."
• SGI: "SGI acknowledges the SNMP vulnerabilities reported by CERT and is currently investigating. No further information is available at this time."
• Cisco: "Cisco Systems is addressing the vulnerabilities identified by VU#854306 and VU#107186 across its entire product line."
• Netscape: "As a result, we have created fixes which will resolve the issues, and these fixes will appear in future releases of our product line. To Netscape's knowledge, there are no known instances of these vulnerabilities being exploited and no customers have been affected to date."
• Lucent: "Fixes for the rest of the affected product portfolio will be available shortly."
• HP: "Patches in process. Watch for the associated HP Security Bulletin."
• Novell: "The SNMP and SNMPLOG vulnerabilities detected on NetWare are fixed and will be available through NetWare 6 Support Pack 1 & NetWare 5.1 Support Pack 4. [None of which are available yet.]"
• Compaq: "At the time of writing this document, COMPAQ continues to evaluate this potential problem and when new versions of SNMP are available, COMPAQ will implement solutions based on the new code."
• Redback Networks: "Redback Networks, Inc. has identified that the vulnerability in question affects certain versions of AOS software on the SMS 500, SMS 1800, and SMS 10000 platforms, and is taking the appropriate steps necessary to correct the issue."
• Network Computing Technologies: "Network Computing Technologies has reviewed the information regarding SNMP vulnerabilities and is currently investigating the impact to our products."
• DMH Software: "It is unclear at this point if our snmp-agent is sensitive to the tests described above."
• Avaya: "Avaya Inc. acknowledges the potential of SNMP vulnerabilities and is currently investigating whether these vulnerabilities impact Avaya's products or solutions. No further information is available at this time."
• AdventNet: "The release of AdventNet Inc's. Service Pack correcting the behavior outlined in VU#617947, and OUSPG#0100 is scheduled to be generally available to all of AdventNet Inc.'s customers by February 20, 2002."