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.'"

8 of 187 comments (clear)

  1. Re:Impossible! by 1s44c · · Score: 5, Insightful

    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.

  2. A confusing summary on /., let me try to do better by Above · · Score: 5, Informative

    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.

  3. Re:Open sores == fail by NoNonAlphaCharsHere · · Score: 5, Insightful

    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.

  4. APK's monolithic hosts file by Culture20 · · Score: 5, Funny

    APK's monolithic hosts file is looking pretty good at the moment.

  5. Re:10 years ago by Above · · Score: 5, Informative

    This particular vulnerability applies only to BIND9 operating as a recursive resolver. BIND9 operating in authoritative mode, similar to how TinyDNS operates, is unaffected. Had you properly deployed BIND9 for the same purposes you are using TinyDNS you would not had been impacted by this issue.

  6. Re:A confusing summary on /., let me try to do bet by surgen · · Score: 5, Interesting

    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.

  7. Re:Tip of the iceberg by kqs · · Score: 5, Informative

    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.

    Except that the assertion isn't the problem. The problem is that BIND allows bad data into its cache. The assertion detects this and crashes BIND before the bad data becomes an exploit.

    Now, there still may be a way to execute code using this method, but the assertion has alerted everyone to this problem so I expect this particular problem to be solved quickly. And thanks to the assertion-crashes, people will be forced to upgrade rather than running a vulnerable version for the next 5 years.

    I'd prefer software without bugs, but since that's impossible, I'll happily take BIND.

  8. etckeeper by Compaqt · · Score: 5, Informative

    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