Slashdot Mirror

← Back to Stories (view on slashdot.org)

Security Hole In SNMP

Posted by timothy on from the so-never-mail-passwords dept.

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.

16 of 267 comments (clear)

  1. Not much scanning for it yet. by UnderAttack · · Score: 3, Informative

    So far, DShield does not have too much scanning for it yet (data).
    But I guess the kiddies are still sharpening the tools...

    --
    ---- join dshield.org Distributed Intrusion Detec
  2. From patches to kings by caferace · · Score: 3, Informative
    Seeing as how CERT was aware of this last summer, and has been working with vendors (ALL the big names) to get it corrected at least we can hope that the patches are available.

    Getting them installed may be a different story. There are probably a lot of "forgotten" SNMP devices out there...

  3. Not a SNMP hole by Anonymous Coward · · Score: 4, Informative

    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).

    1. Re:Not a SNMP hole by Quill_28 · · Score: 4, Informative

      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.

    2. Re:Not a SNMP hole by tqbf · · Score: 4, Informative
      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.

    3. Re:Not a SNMP hole by tqbf · · Score: 4, Informative

      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.

  4. End of email from SANS... by heliocentric · · Score: 5, Informative

    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

    --
    Wheeeee
  5. Re:What is the flaw? by kindbud · · Score: 4, Informative

    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.

    --
    Edith Keeler Must Die
  6. Re:Alternatives by stinky+wizzleteats · · Score: 3, Informative

    SNMP is well known to be a security problem (at least in the networking community). The answer is to cut all of it off at your firewall, and make sure your internal networks are zoned appropriately. The best way to deal with it right now is to put all your equpiments' management addresses in a management VLAN, of which none of the user ports are members, and then control access to it via the router you'll use to get to the VLAN.

  7. Re:SNMP's a pretty damned scary protocol anyway by Quill_28 · · Score: 3, Informative

    Ever heard of SNMPv3?

  8. Wrong summation (again). by hardaker · · Score: 5, Informative

    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.

    --
    The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
  9. Re:What is the flaw? by Florian+Weimer · · Score: 4, Informative
    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.)

  10. Re:Alternatives by gmack · · Score: 3, Informative

    This is why I've always tended to run snmp on a non routable address block. It's saved me a few times.

  11. Those evil Microsoft d00ds by Zico · · Score: 5, Informative

    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."

  12. There is not secret by RobertGraham · · Score: 3, Informative

    The advisories contain a link to a tool that will test the vulnerability. There are no secrets being kept, it's all out in the open. The problem is that no "easy-to-use" tool has been created (except for checks that have been added to scanners).

  13. Re:CERT Considered Harmful. by ryanr · · Score: 3, Informative

    According to ZDNet, this vulnerability was reported to CERT by a research team one year ago. It was only today announced in an advisory. CERT maintained a multiple-month window of time to suppress the advisory.

    And yet, looking at the advisory, the most important vendors don't yet have patches . In particular, Microsoft, Cisco, and Sun remain vulnerable, with no released patches!

    The entire rationale behind keeping vulnerabilities quiet is to enable vendors to fix the problem before the exploit falls into the hands of attackers. The entire rationale behind CERT's very existance is to act as a clearinghouse for vulnerabilities so that fixes can be coordinated prior to announcements. Virtually every credible security researcher has repeatedly exclaimed that CERT's model doesn't work. I can't imagine a clearer vindication for CERT's critics than this.

    Not that I'm trying to validate CERT's model mind you...

    They were somewhat forced into releasing today. There was a leaked early version of the advisory (with no details) that had a release date of February 20th. Details were spilling out from various sources. Given how many patches were announced today after the advisory, it's safe to say that those vendors must have been pretty close to being ready.

    It also demonstrates that it's not possible to try and give that many vendors that much warning, and not have leaks.