Has anyone else heard of this SNMP problem? Are we up to date with the security fixes on stable, etc?
Here is a quick excerpt (CRYPTO-GRAM, March 15, 2002): SNMP Vulnerabilities SNMP is the Simple Network Management Protocol, the most popular protocol to manage network devices. Hundreds, possibly thousands, of products use it. Last fall, a group of Finnish researchers discovered multiple vulnerabilities in SNMP. By exploiting the vulnerabilities, an attacker could cause a denial-of-service attack, and in some cases take over control of the system. The vulnerabilities concerns SNMP's trap-handling and request-handling functions, and stem from problems in the reference code (probably) used inside the Abstract Syntax Notation (ASN.1) and Basic Encoding Rules (BER). The SNMP vulnerabilities affect hundreds of different devices: operating systems, network equipment, software packages, even things like digital cameras. It's a BIG deal. It's actually a bigger deal than has been reported. ASN.1 is used inside a lot of other applications, such as OpenSSL. These vulnerabilities aren't limited to SNMPv1; that's just the only thing that's been well-publicized at this point. (The recently reported problems in mod_ssl and Apache are apparently related to this, too.) The history of the vulnerability's discovery and publication is an interesting story, and illustrates the tension between bug secrecy and full disclosure. A research group from the Oulu University Secure Programming Group in Oulu, Finland, first discovered this problem in October 2001, and decided not to publish because it was such a large problem. CERT took on the task of coordinating the fix with the major software vendors, and has said that the reason publication was delayed so long is that there were so many vendors to contact. CERT even had problems with vendors not taking the problem seriously, and had to spend considerable effort to get the right people to pay attention. Lesson #1: If bugs are secret, many vendors won't bother patching their systems. The vulnerability was published on 12 February. Supposedly, this was two weeks earlier than planned, and because the story was leaking too much. CERT felt that early publication was better than widespread rumors. Some companies were caught off-guard. Even though they had months to patch their systems, they weren't ready and needed those two extra weeks. Some companies didn't bother to start worrying about the problem until publication was imminent. Lesson #2: It is only the threat of publication that makes many" vendors patch their systems. (To be fair, many companies did a great job proactively patching their systems. And in many cases, the patches were not trivial. Some vendors were swamped by the sheer number of different products and releases they had to patch and test. And I stress "test", because patching mature code carries a strong probability of either not fixing the problem or of introducing new problems.) When CERT finally published and the Oulu Web site went live, there were all sorts of reactions. Some tried to capitalize on the announcement to sell their products; others tried to minimize it. Many vendors had no idea if they were vulnerable or not But because publication included demonstration code -- the PROTOS tool -- vendors and security companies were able to test networks and equipment. Lesson #3: Publication must include enough information to reproduce the vulnerability; otherwise, there's no way for anyone to determine how serious the threat is. And Lesson #4: If there is no way to independently verify the vulnerability, then organizations are forced to rely on information from potentially biased sources. As of this writing, there have been no credible reports of this vulnerability being exploited in the wild. Counterpane's monitoring has not detected any of our customers being attacked via this vulnerability. This is not to say that no one has -- writing an attack tool is a straightforward programming task -- but no one has published such a tool and put it in the hands of the script kiddies. Lesson #5: Publication does not automatically mean the vulnerability will be exploited. So far we've been lucky. But a tool could show up at any time, so relying on that luck would not be smart. And even though everyone has been urged to patch their systems and products, some will not. Even if it takes months before someone writes an attack tool, it will work against a surprisingly large subset of systems. Lesson #6: Publication increases the likelihood that a vulnerability will be exploited. And there are a lot of systems for which patches will never be available. Many router vendors have gone out of business in the last few years, and not every mom-and-pop software company out there has the money or clue to replace their hardware because their code has a problem. Lesson #7: Since many, many systems will remain unpatched, this vulnerability will pose a risk for years to come. At Counterpane, we were able to make use of the public demonstration code to quickly write filters for our Sentry and push them down to our customers' networks. We did this within hours, so even if they didn't patch their systems we could monitor them for evidence of exploitation. We patched our own Sentry. This wasn't perfect -- in some systems the attack didn't show up in their audit logs -- but it let us know which systems would benefit from other security tools, like IDS signatures tuned to detect the PROTOS tool. We collected and maintained a list of intrusion detection signatures for Snort, RealSecure, CiscoIDS, Network Flight Recorder, etc., that were specifically designed to collect the PROTOS' tool's test packets. We also sent out an advisory to our customers -- a voice of reason among the slightly hysterical news articles -- and made our Network Intelligence group available in a conference call to reassure them. We made our research available to the FBI and other security organizations. Lesson #8: Vigilant monitoring provides another layer of security, if and when products and patches fail. While these vulnerabilities are serious, the fact that SNMP is vulnerable should not come as a surprise to anyone. Vulnerability "U7" in the SANS Top 20 talks about SNMP. SANS's recommendation: "If you do not absolutely require SNMP, disable it." This was good advice when the list was released, and it's good advice now. CERT advisory: <http://www.cert.org/advisories/CA-2002-03.html> <http://www.cert.org/tech_tips/snmp_faq.html> Counterpane advisory: <http://www.counterpane.com/alert-snmp.html> Oulu's analysis and PROTOS test suite: <http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/snmpv1/> Analyses and articles: <http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2847924,00.html> <http://www.theregister.co.uk/content/4/24167.html> <http://www.infoworld.com/articles/op/xml/02/03/04/020304opsecurity.xml> -- http://www.eskimo.com/~xeno [EMAIL PROTECTED] Physically I'm at: 5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.