Dear List: According to Bruce Schneier, there is a security problem with OpenSSL's ASN.1 implementation. I have searched the OpenSSL Web FAQ and the list archive, but have not found any mention...
Any comments/feedback will be appreciated. Many thanks! Andrew. -------------------- SCHNEIER dixit: 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 Schneier CRYPTO-GRAM Newsletter (Relevant article only) ------------------------------------------------------------------ ----- Original Message ----- From: "Bruce Schneier" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 15, 2002 6:38 PM Subject: CRYPTO-GRAM, March 15, 2002 > CRYPTO-GRAM > > March 15, 2002 > > by Bruce Schneier > Founder and CTO > Counterpane Internet Security, Inc. > [EMAIL PROTECTED] > <http://www.counterpane.com> > > > A free monthly newsletter providing summaries, analyses, insights, and > commentaries on computer security and cryptography. > > Back issues are available at > <http://www.counterpane.com/crypto-gram.html>. To subscribe, visit > <http://www.counterpane.com/crypto-gram.html> or send a blank message to > [EMAIL PROTECTED] > > Copyright (c) 2002 by Counterpane Internet Security, Inc. > > > ** *** ***** ******* *********** ************* > > 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> > > > ** *** ***** ******* *********** ************* > > > CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, > insights, and commentaries on computer security and cryptography. Back > issues are available on <http://www.counterpane.com/crypto-gram.html>. > > To subscribe, visit <http://www.counterpane.com/crypto-gram.html> or send a > blank message to [EMAIL PROTECTED] To unsubscribe, > visit <http://www.counterpane.com/unsubform.html>. > > Please feel free to forward CRYPTO-GRAM to colleagues and friends who will > find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as > it is reprinted in its entirety. > > CRYPTO-GRAM is written by Bruce Schneier. Schneier is founder and CTO of > Counterpane Internet Security Inc., the author of "Secrets and Lies" and > "Applied Cryptography," and an inventor of the Blowfish, Twofish, and > Yarrow algorithms. He is a member of the Advisory Board of the Electronic > Privacy Information Center (EPIC). He is a frequent writer and lecturer on > computer security and cryptography. > > Counterpane Internet Security, Inc. is the world leader in Managed Security > Monitoring. Counterpane's expert security analysts protect networks for > Fortune 1000 companies world-wide. > > <http://www.counterpane.com/> > > Copyright (c) 2002 by Counterpane Internet Security, Inc. > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
