Slashdot Mirror
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.
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
This appears to be quite serious... check out the list of vendors: http://www.cert.org/advisories/CA-2002-03.html#ven dors
It includes Cisco, Microsoft, HP, Sun, Novell, and many others. When it comes to SNMP bugs, it would seem that most vendors are created equal.
Natural != (nontoxic || beneficial)
Getting them installed may be a different story. There are probably a lot of "forgotten" SNMP devices out there...
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).
Who's in charge of Acronyms around here? It's not an SMTP problem!
"You are not a beautiful and unique snowflake."...Tyler Durden
What do you expect from a protocol named Security's Not My Problem?
Well, yes and no. It sounds like there are some assumptions that are commonly made when processing traps. However, if someone wants to be malicious, those assumptions may not hold. But, the protocol isn't necessarily flawed. It just means that developers need to check their assumptions (like they should all the time).
"Let your heart soar as high as it will. Refuse to be average." - A. W. Tozer
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
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
Even without the aforementioend flaws (whatever they are), SNMP is a truely horrible protocol. The only real security in most implementations is based on IP Address and SNMP Domain Name. Most network devices will be "polite" with their IP addresses (especially when DHCP is enabled), so taking over an IP address is rarely a problem (assuming IP spoofing doesn't suit your needs). And the Domain Name is rarely difficult to brute-force.
But this assumes that security is even configured at all. So many network devices support SNMP these days that anything less than perfect administration can result in all kinds of trouble. Be honest: how many networks that you know of don't have several devices set to the "public" domain with no address filtering. Hello, Denial of Service.
After all these years of (alleged) focus on network security, I'm pretty shocked that there isn't a widely deployed standard based on public-key encryption, digital signatures, and other means of access control. You can't really make the argument that this is rocket science anymore...
Help save the critically endangered Blue Iguana
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.
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!
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.
IANA Programmer, IANA Sysadmin, I'm just a user... Mod appropriately, please.
But still, this notice strikes me as excellent. First, it draws attention to a hole that can be patched, and I'm sure a number of programmers are grabbing down what source they can to implement a fix for it. Corporations who bitch and moan about how security flaws should not be broadcast to the world strike as not being willing to fix them quickly, or are willing to sell packages with flaws in them and hope to get away with it. Yay CERT!
Second, while the magnitude of impact may be great, it's sure a change from the near-weekly "a hole has been found in Microsoft Product X" announcements we get. It stands out because we don't get "Major security hole in basic technologies" announcements very often - usually they're linked to some broken MS implementation of it, or a proprietary protocol looking for adoption.
Plus, it goes to show that the Internet is an interdependent community that relies on basic technologies to work, rather than perpetuating the myth that Microsoft *is* the Internet. And the community will either fix the problem, or adopt a new, more rigorous standard.
And speaking of rigorous, isn't it nice that the basic standard has stood up this long under heavy usage? Can MAPI32 say the same thing? Or VBScripting? Or IIS? Or...
I love watching big stuff break for two reasons - I'm a pyromaniac who loves to see thinks go up in flames, and I'm always uplifted by a well-executed community response.
GMFTatsujin
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.)
This is why I've always tended to run snmp on a non routable address block. It's saved me a few times.
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?
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).
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.