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.
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)
Who's in charge of Acronyms around here? It's not an SMTP problem!
"You are not a beautiful and unique snowflake."...Tyler Durden
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
Let's not send the wrong message here... they said turn it off if you don't need it. Don't blow up your car just so no one will steal it. Lock the doors!
Similarly, SNMP is a really useful tool that administrators should be making even more use of. They shouldn't get rid of it just because of this bug or the fact that lots of people use defautl passwords. That doesn't make the tool bad. Fix the bug(s). (Have there been other bugs recently?) Set the passwords. Save the car.
"Let your heart soar as high as it will. Refuse to be average." - A. W. Tozer
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
1) Don't run it if you don't use it.
2) If you use it and implemented it the way it's supposed to be implemented (listen only to trusted hosts) - upgrade with the next roll-out.
3) If you use it but don't know what you are using - get a clue, so that you fall in 2). Every lister on your box can fail you, be prepared, you have none to blame but yourself.
you know, for a while I was with most of you, ready to take up the chant at the slightest hint of security through obscurity:
"Release information about security flaws immediately, you corporate hoodlums!"
But then came the sshd exploit. I run a small-time server on a DSL connection, and before the announcement I got zero exploit attempts. Since the announcement, I get 4 to 5 attempts per day.
What does this tell me? Keeping vulnerabilities secret for a while, while not the final answer, can save headaches, money & time by not having to clean up after every last idiot with a root kit. The serious crackers are always going to have the latest exploits, but keeping them out of the hands of script monkeys might just be worthwhile.
I don't mean this to sound as confrontational as it will, but before y'all get up on your soapboxes, take a look at your server logs and see what's really going on.
I am the very model of a modern major general!
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.
From the looks of this announcement, this may well be the most serious security vulnerability ever published; it's a root hole in literally every piece of Internet infrastructure deployed to date (assuming lack of filtering; but remember that most networks aren't properly firewalled off internally from customers and insiders). If CERT can't successfully coordinate a response to this vulnerability, why should we trust them with any other problems?
SNMP is a bad protocol. It's universally hated and derided by implementors. This is an amazingly great example of the problems that spring from shallow implementation gene pools; most of these vulnerabilities are probably due to code in CMU and UCD's (related) SNMP libraries. This is an excellent example of why it is critical to diversify implementations of core protocols on the Internet. Some incredibly hardworking researchers have been working towards these ends for years; the network engineering community has largely responded to them with derision . Think about this.
This problem was so subtle that it wasn't detected for years and years, even though the vulnerability boils down to simple buffer overflows. This is because SNMP is an ASN.1/BER protocol. There are like four bazillion ways to represent a length in BER. Talented researchers have continuously reiterated the need for simple, modular protocols to replace the rickety ad-hoc mess we use now. They have again met with derision from the network engineering community. Think about this.
Finally, the fact that SNMP is an insanely complicated protocol has not been lost on attackers. The very fact that CERT "accelerated" the release of this advisory indicates that they knew attackers "could" find some of these vulnerabilities. The fact is that some black hats almost certainly have worked this out. If we had published last year, when the discovery was made, just like the overwhelming majority of other vulnerabilities, the problem would have been fixed a year ago. If you manage a large network, how do you know you haven't already been compromised? Attackers have had years to exploit these problems without you knowing about it.
Why isn't anyone learning from these mistakes?