Slashdot Mirror
Potential 0-Day Vulnerability For BIND 9
Morty writes "BIND, the popular DNS server software, has been crashing all over the Internet. The root cause is believed to be a 0-day vulnerability in BIND's resolver. The ISC has issued an alert. Quoting: 'An as-yet unidentified network event caused BIND 9 resolvers to cache an invalid record, subsequent queries for which could crash the resolvers with an assertion failure. ISC is working on determining the ultimate cause by which a record with this particular inconsistency is cached. At this time we are making available a patch which makes named recover gracefully from the inconsistency, preventing the abnormal exit.'"
Alert DJB at once!
I had to choose which DNS server I would deploy on my servers. I went for TinyDNS as it had all the same features and security promises. Man am I glad to have considered security over popularity.
Oh for fuck's sake, it's an assertion error. Get over yourself.
It's open source, and has had years to mature...so many eyes on it that this couldn't possibly happen.
We don't even know what is happening yet. Maybe it's just a DOS, maybe it's a potential exploit. What we do know is that no-one has any need to put recursive DNS servers on the internet unless they are running an ISP or a DNS service.
Of course it can happen, it's just less likely to have problems than software with only a few sets of eyes on it. In addition, I had patches installed on my linux machines this morning, before I was even aware the problem existed. How's that for turnaround.
BIND is written by Internet Systems Consortium aka ISC, a non-profit that does various public benefit things for the Internet. The summary links to an alert from the Internet Storm Center aka ISC, a project of the SANS Technology Institute. There is no relation between these two ISC's, in this case the first authors the software, and the second tracks vulnerabilities. I'm sure by using a link to SANS many people on /. who are not familiar with these two ISC's will get them confused.
The link in the summary also goes to a preliminary version of the advisory. The correct, full summary is available on Internet Systems Consortium's web site as CVE-2011-4313.
I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something, and that is used by bad-actors before the vendor is aware and able to fix the issue. In this case the bug simply crashes the server; there's no remote root or other exploit, and at this time there is no evidence of bad-actors using this bug at all. Rather it appears something interesting (unusual, perhaps put there intentionally) appeared in the DNS, and it triggered a bug in the software.
Some historical context may help. BIND8, for those who used it, was a pile of poo. It had a huge number of security issues and other problems and was generally a nightmare for sysadmins. Many people stayed on BIND 4.9.x for a very long time because of the issues in BIND8. When ISC launched BIND9, they wanted to change this perception. The action relevant to this bug is that BIND9 was designed to be full of assertions and other checks in the code. The goal was to catch any badness early, and if it was uncorrectable crash in a predictable way. The thought was that crashing with a core dump where you can fix the problem is far better than running off with bad data that could eventually be used in some sort of remote-root exploit.
This issue is sort of the payoff of that philosophy. Rather than taking this bad data and giving a remote hacker access to the machine BIND9 caught it with an assert, logs a useful message and core dumps. This is a big part of why 0-day leaves the wrong impression with me, "denial of service vector" seems to perhaps be a more accurate description. Sure, we could have a lively debate about if crashing is preferred or not, but I think most of the administrators who lived through BIND8 prefer the BIND9 procedures.
Internet Software Consortium also offers support for BIND (and DHCP). I'm amazed how many people run large, production name servers on BIND yet don't have a cheap support contract. If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor.
I can see this is going to be a long thread full of trolls about open source, but the fact of the matter is that an application "crashing" (really ABENDing) due to an assertion failure is actually a sign of software doing what it was designed to do. Assert statements are used to check for "impossible" conditions, and have the program scream and die if one is found. So what we have here is a careful programmer's backstop doing its job.
Open sores software == fail. Once again full of security holes that the "many eyes" failed to spot.
Unlike windows which never has remote crashes or remote execution of arbitary code problems. Tell me does microsoft.com still block ping? Why is that again?
APK's monolithic hosts file is looking pretty good at the moment.
Your understated discretion just takes my breath away.
I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something,
Something like cause a denial of service?
yes yes, but thats very limited. Yes, you can deny service.... but it can be started back up. The only loss is availability of the service, the integrity of the service is uncompromised. It isn't allowing someone to make you serve up their data, it isn't allowing anyone to dump data they shouldn't have, it isn't allowing them to change, erase or anything your data.
Essentially... a DDOS means you are hosed until they stop or you can upgrade... the term 0-Day tends to be used to refer to actualy security issues, where the denial of the service is the least of your worries. Patching isn't good enough because, they got a window in, and could have installed a root kit.
"I opened my eyes, and everything went dark again"
Thanks for the clear explanation.
If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor.
Very true. Its funny, that this morning I had applied security patches to a debian stable box and thought "hmm, looks like BIND is getting fixed, wonder what thats about" before this even got posted to slashdot.
Microsoft code would typically leave out the assert, and happily stumble along. At least with the assert, you know what AND WHERE the Bad Thing (TM) happened, and have a clue as to where to look to fix it.
The "assertion"-problem is only tip of the iceberg.
If an assertion fails, this usually means that someone managed to make the code behave in an unintended way. Since the affect occurred simultaneously at several providers all over the world, this indicates a coordinated attack. The chances are real, someone managed to exploit a buffer overflow (or similar) in BIND.
So we have to look seriously into the possibility that people have a way to execute code with the same permissions as BIND has.
When i got the information this morning, this was an alert topic.
Yours, Martin
I am glad I took my lumps and disabled public recursive resolving many years ago on my BIND installations. Only do that for local IP ranges! This eliminates all the resolver issues. Also I found that when the DNS server was open I was getting a constant stream of unusual TXT lookups which were for oddball domains. These contained many K of data. I suspect these requests were fake source IP requests being used as some sort of bandwidth DOS attack.
Unbound, also from NL Netlabs, is a recursive resolver. NSD is an authoritative server.
The problem is with Bind as a recursive resolver, not as an authoritative server.
That's not how liability works. You are talking about some kind of warranty.
First, this has nothing to do with Microsoft, so there is no need to drag them into it.
Second, I am not questioning the need to test for errors, or that sometimes the correct thing to do when an error is encountered is die. I am challenging your position that overall the software is doing what it was designed to do and this is not a bug. The assertion itself is fine - there are reasons why the cache may have been corrupted and you want to kill the program (hardware error, tampering with files, etc). However, in this case the check should have been done BEFORE the data was put into the cache, when the correct response would have been to simply reject the message. Failure to do that check is a bug.
I'm not sure how to square large production name servers with "generalist deployments". Clearly the small admin can do without a support contract. However I've seen large ISP's, supplying service to millions of customers with no support, and I think that's insane.
If you go back to ISC's Software Support page you'll notice "Advance Security Notifications". Depending on the nature of the issue, ISC's support customers often receive notification before BIND-announce. I believe this particular issue went out in all forums pretty much at the same time due to the severity, but lesser issues may be released in a staged fashion.
By the way, another thing people who are wont to mess with their /etc should keep in mind is etckeeper. It versions your /etc, by default in bazaar, but it's also supposed to work with git, hg, etc. It has triggers set so every time you install something, it does an automatic checkin.
You can also manual commits, too, along with a message.
Good for people who want to know what the config files looked like when they were working a week ago.
Click to install (Debian and friends)
I'm not a lawyer, but I play one on the Internet. Blog
So this is a patch to deliberately break the carefully constructed "graceful death" preventing a potential exploit?
Sounds like a GRAND idea...
Finally had enough. Come see us over at https://soylentnews.org/
As a long-time BIND hater, I recently switched from djbdns/tinydns to NSD. I figured if it's good enough for a few root servers it was worth a look. It's very efficient and fast, uses standard zone files, fully ipv4/ipv6 dual-stack transparent, and is DNSSEC aware. Very pleased so far.
I'm an animal lover -- they're delicious!
I've never known 0-day to mean that. 0-day has to me always meant an exploit in the wild before the author is aware of it vs. an exploit taking advantage of a bug that was fixed a month ago but people haven't applied the patch.
I use TreeWalk. Since it's an implementation of BIND, do I need to apply this patch to it, and if so how?
Did a little looking into it and, though I'm generally a fan of DJB's wares, unpatched qmail does indeed have the problem of accepting all mail for configured domains, regardless of localpart (box) validity. Which means DSNs will be sent for bad addresses, and since SMTP provides no way of validating senders, backscatter occurs. This is the term for it, by the way.
I've seen plenty of spam using the mechanism. It's a real problem.
Patches are available. But, yeah, DJB's licensing made even patching problematic for the longest time. Thankfully, he's conceded on that point. Which suggests to me he's not dogmatic or unreasonable, just rigidly principled.
I run Postfix, too. Love it. The licensing limbo was part of my decision to go with Postfix, though there were a number of factors. But I still run DJB's tinydns and dnscache.
There has not been a single remote-root exploit in BIND9 since it was offered up to the world circa 2001. It was a complete rewrite with new goals, so taking BIND 4.x or BIND 8.x as examples isn't really relevant.
ISC is also completely open about security issues, listing them all on the web site and registering them with the CVE Registry.
As I stated in another post, the goal of BIND9 was use use various constructs (like assertions) to check data integrity, where possible on the fly and where not practical in a way that causes a core dump. That to fail safe was the best option, and crashing in a way the bug could be fixed was a positive. If you view the advisories against BIND9 you'll see that strategy has worked very well. Of course there's no reason not to lock any application in a VM, jail, chroot or whatever to get additional security, but I think the track record of BIND9 compared to most other major open source software is decent.
BIND is also "full featured". Many of the folks here reference alternatives like NSD, tinyDNS, or Unbound which provide limited functionality compared to BIND. Obviously if you're willing to limit the functionality you limit the bug exposure, but that's true both if you use software that doesn't include the functionality but also if you disable that functionality in BIND. For instance the bug in question affects recursive resolvers only, if your BIND9 instance is an authority only configuration there is no exposure.
I'm afraid most of BIND's bad reputation comes from BIND 4.x and BIND 8.x, both of which were quite bad (for different reasons). BIND9 was a departure, and now ISC is working on BIND 10, which should be yet another large leap forward.