Leaf folks,
First, let me say that I'm not one to be regularly fwding alerts
around and such. But the following alert issue cropped up in my inbox
and and search for SNMP in the leaf archives didn't mention any recent,
relevant discussions so it might be relevant news. In all honesty I'm
not the best equipped to tell, other than to say that "SNMP" appears in
my config files, albeit it commented out by default IIRC. I present this
for possible consideration by more learned individuals.
In summary: there's a new, big, bad, pervasive exploit for SNMP.
Quoted at the end is the relevant part of the monthly newsletter from
CounterPane.Com - they seem genuine to my eyes. The newsletter is
available in it's entirety online via:
http://www.counterpane.com/crypto-gram-0203.html
Because of the pervasive existence of SNMP, the apparent
less-than-justified media attention and potential (DOS and/or root?) of
the problem I'm mentioning it in this list. Even if it doesn't affect
the default leaf install it may be significant to netadmins.
My personally-interested question is: are there any raw components
of the leaf (Dachstein) distributions that are effected by this
vulnerability? Any sub-components? Do we need to update our boxen?
thanks,
scott
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
<extract from 02/03/15 crypto-gram newsletter, available at
http://www.counterpane.com/crypto-gram-0203.html>
> 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>
>
>
> ** *** ***** ******* *********** *************
--
There are only two things to worry about:
-- either you are UNHACKED or you are HACKED.
If you are UNHACKED, then there is nothing to worry about.
But if you are HACKED, there are two things to worry about:
-- either you HAVE DATA LOSS, or you DO NOT HAVE DATA LOSS.
If you DON'T HAVE DATA LOSS, there is nothing to worry about.
If you HAVE DATA LOSS
-- ske
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
