Forgot your password?
typodupeerror
Networking Security The Internet IT

Potential 0-Day Vulnerability For BIND 9 187

Posted by Soulskill
from the bind-your-own-business dept.
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.'"
This discussion has been archived. No new comments can be posted.

Potential 0-Day Vulnerability For BIND 9

Comments Filter:
  • by Anonymous Coward on Thursday November 17, 2011 @10:38AM (#38085314)

    Alert DJB at once!

  • 10 years ago (Score:4, Informative)

    by ghn (2469034) on Thursday November 17, 2011 @10:39AM (#38085324)
    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.
    • Re:10 years ago (Score:5, Informative)

      by Compaqt (1758360) on Thursday November 17, 2011 @10:46AM (#38085410) Homepage

      Another small DNS server is MaraDNS. It's considered a good alternative to BIND [google.com].

      Being a lot smaller, it's easier to secure.

      If you're just running a DNS cache on your desktop, check out dnsmasq. Click to install [deb](Deb/Mint/Ubuntu)

      • by swalve (1980968)
        Agreeing with dnsmasq. Bit of a bitch to set up just right, but I've got it working now running my firewall/router.
        • etckeeper (Score:5, Informative)

          by Compaqt (1758360) on Thursday November 17, 2011 @11:53AM (#38086364) Homepage

          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 [deb] (Debian and friends)

          • Re:etckeeper (Score:4, Interesting)

            by X0563511 (793323) on Thursday November 17, 2011 @12:38PM (#38086978) Homepage Journal

            Awesome!!

            I've been known to keep subdirectories of /etc as SVN repository checkouts, but that grabs the whole thing!

            The only thing I'd be worried about is accidentally uploading sensitive data (hashes and such).

            • by Compaqt (1758360)

              Yeah, I used to use the old-school ci and co commands from rcs [deb] (anybody remember that?).

              In fact, you can still use it to version specific files you care about without pulling in everything.

              One thing which is an annoyance for me is the huge lines of binary represented as text in Virtualmin config files. Haven't found a solution to that.

              You're right about the sensitive data. Anybody have a good solution?

        • by AvitarX (172628)

          I thought it was quite pleasant to setup.

          I use it at work, where we have 2 sites connected with VPN (and each site with dnsmasq), and it works fantastically as a DHCP server, and dns server, allowing all computers to be accessed as computer.sitename

      • by gmack (197796)

        Better yet use Unbound resolving only nameserver since it supports signed zones.

      • Re:10 years ago (Score:4, Informative)

        by MaraDNS (1629201) on Thursday November 17, 2011 @02:41PM (#38088748) Homepage Journal
        Let's not forget Unbound [unbound.net], which may be faster than MaraDNS's 2.0 recursive resolver. Then again, I just got some funding from a sponsor to work on speeding things up. Also, Unbound has DNSSEC -- something MaraDNS doesn't have.

        And, of course, there is Power DNS [powerdns.com], another excellent DNS server.

        Then again, there's something to be said for being able to set things up using only a three-line configuration file [maradns.org] and a 64k binary works nice for embedded places like OpenWRT where Unbound and PowerDNS won't fit.

        - Sam

    • by janeuner (815461) on Thursday November 17, 2011 @10:48AM (#38085430)

      It's hard to go wrong with DJB*.

      • by afidel (530433) on Thursday November 17, 2011 @10:54AM (#38085510)
        Unless you have to actually work with him.
        • by X0563511 (793323)

          Glad to know I'm not the only one who thinks DJB makes no sense at all. Every time I see it it takes me half a freaking hour to figure out how to update a zone.

          • I think GP was referring to how inflexible DJB the person can be. But certainly their comment could be used to refer to the software as well.

            Not only did DJB reject the design and development practices that left BIND such a threat but he also rejected a number of usual conventions around software management/installation/licensing. In his defense, he did it because he believed the conventions were bad. His own version of things makes sense and works well, but it's definitely weird if you're coming new to

            • by afidel (530433)
              I was referring to him as a person, the fact that some of his idiosyncrasies bleed over to his software is the least of the issues I have with him =)
      • by Compaqt (1758360)

        Wasn't there some sort of license problem with DJB stuff? Like the slowness of Java applets in the early 1990s, I don't think Slashdotters will let him live that down.

        • I don't know about his DNS server, but qmail had some goofy license that meant everything was just a series of patches.

          He's since released it into the public domain though.

          • by Anonymous Coward

            He had no license, believing that having no license and no copyright meant it was in the public domain. US law says otherwise, and DJB disagreed. Unfortunately, that put the software in limbo.

            Eventually, a license permitting distribution of unmodified source was added. This, of course, meant compiled versions and built-in tweaks to make it work with certain compilers (like GCC) and distributions were not permitted to be distributed. Patches were granted as an exception. Distributors were too lazy to bu

            • My understanding was while that he permitted source redistribution, he insisted that it be only distributed unmodified, and never binary distribution. He also generally refused to accept patches, apparently thinking his pristine work ought to be good enough for everyone. (It was good, but needed features as time went on.) This meant that any "improvements" could only be distributed as patches. As a result, only source-based distros had an easy time packaging it, since sources + patches + build instructi
          • Re:10 years ago (Score:5, Informative)

            by gmack (197796) <.gmack. .at. .innerfire.net.> on Thursday November 17, 2011 @12:35PM (#38086934) Homepage Journal

            The major problem with Qmail was it's design simply didn't take into account the possibility of a bad return address. The downside was that it couldn't bounce during reception and so was forced to generate a bounce message instead and not only did spammers plug up the queue with bad messages, it ended up being used for reflector attacks where the attacker set the target's address as the return and sent messages that would bounce to many different servers. The whole problem ended up being so bad that many that many mail admins considered servers running Qmail to be almost as bad as an open relay and there were people who actually maintained blacklists of servers running Qmail and that was right about when I stopped using it but I hear there have been patches to fix the worst of it's flaws since then.

            In short: it was secure for only some definitions of secure and for everything else DJB ignored the problem.

      • Re:10 years ago (Score:4, Interesting)

        by MaraDNS (1629201) on Thursday November 17, 2011 @02:52PM (#38088888) Homepage Journal

        Don't get me wrong, djbdns is an excellent DNS server. Unfortunately, it hasn't been updated for over 10 years and, since then, three different security holes have been discovered the djbdns package, the root server list has been updated, errno has been changed to make Linux more thread safe (requiring a patch to compile it), and so on.

        djbdns can work -- but it requires patching by hand or using an unofficial fork like Zinq [sourceforge.net] (which appears to still be supported -- the last release was done this year).

        (I can also murmur darkly about the fact that djbdns uses a circular queue instead of a LRU for its cache, its lack of a Windows port, its need to use external helper programs to configure the server, etc., but, then again, its core recursive binary is even smaller than MaraDNS 2.0's tiny recursive binary. And three security bugs in the last decade is better than the 13 security issues in MaraDNS I have had to patch against.)

    • Re:10 years ago (Score:5, Informative)

      by Above (100351) on Thursday November 17, 2011 @11:18AM (#38085800)

      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.

      • by ghn (2469034)
        I was referring to DJBDNS in general and not just the authoritative TinyDNS program. I was also speaking of BIND's security history in general, not only this specific issues.
    • NSD (Score:4, Informative)

      by powdered toast dude (800543) * on Thursday November 17, 2011 @01:22PM (#38087694) Journal
      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.
  • by Above (100351) on Thursday November 17, 2011 @10:58AM (#38085572)

    BIND [isc.org] is written by Internet Systems Consortium [isc.org] 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 [sans.edu] aka ISC, a project of the SANS Technology Institute [sans.edu]. 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 [isc.org].

    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 [isc.org] 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.

    • by NoNonAlphaCharsHere (2201864) on Thursday November 17, 2011 @11:12AM (#38085716)

      BIND8, for those who used it, was a pile of poo.

      Your understated discretion just takes my breath away.

    • by Culture20 (968837)

      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.

      • The point you are missing is "0-day" has come to mean vulnerabilities that can be exploited now for things like remote code execution, takeover, etc . In this case, the bug causes crashes but it is not clear that it makes the computer vulnerable to other security matters.
    • by decula03 (1082847) *

      That's an excellent post, Above.
      thanks!

    • by surgen (1145449) on Thursday November 17, 2011 @11:25AM (#38085906)

      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.

      • by xenobyte (446878)

        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.

        Same here. Debian rules! :)

    • I am 100% with you up until you say, "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 have a couple issues with this. The first is simply that it's perfectly reasonable to expect a good UNIX admin to handle BIND without issue for generalist deployments. The other issue I have is that you don't need a support contract
      • by Above (100351)

        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 [isc.org] 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 ou

    • by Kjella (173770)

      To be honest I completely hate ASSERT-style checks, particularly in multi-user systems. One single logic mistake and boom goes the whole server. With exceptions you can at least have a gradual panic. But when you so often resort to pointer-magic and any unterminated string is a recipe for chaos, well... Though it would be nice if exceptions actually worked, which they don't in C++. Try/catching into some third party code and it'll still segfault on you, completely ignoring your attempt to catch any and all

    • by sjames (1099)

      More to the point, since we have an advisory about it and there's a patch, it can no longer be considered zero day. A true zero day vulnerability is one that only the blackhats know about. Expanding that to include a vulnerability that the vendor doesn't yet understand well enough to patch makes sense. But anyone using the term for a bug that has a patch out to fix it is just being over-dramatic.

    • by Morty (32057)

      Submitter here. Comments:

      0-day refers to the time when the bug is first exploited relative to when it is patched by the vendor. It has nothing to do with whether or not the exploit yield unauthorized access. It is entirely possible to have a 0-day DoS attack.

      There was no evidence on whether or not the bug was triggered deliberately. Hence why the summary referred to it as a "potential" 0-day, and said the problem "is believed to be" a 0-day vulnerability.

      At the time crashes were initially occuring, no p

  • Hurrr, well done guys. Now nobody can download the patches.

    Someone want to set up some mirrors?
    • by Anonymous Coward

      Just updated my Debian boxes with apt a few minutes ago... I suppose you could always grab the source from a distro and compile.

    • by Sipper (462582)

      Hurrr, well done guys. Now nobody can download the patches.

      Right now the ISC website is still responding.

      At least some distributions have already incorporated the patches; for instance, for Debian upgrading simply involves doing an 'apt-get update', 'apt-get upgrade'.
      If updated packages are available, it's generally better to get the packages for Bind9 from the distribution rather than recompiling.

      However the "fix" in this case may not entirely fix the problem; the current repair withholds the DNS response and will keep Bind9 from crashing and shutting down, but th

      • So this is a patch to deliberately break the carefully constructed "graceful death" preventing a potential exploit?

        Sounds like a GRAND idea...
  • by Culture20 (968837) on Thursday November 17, 2011 @11:08AM (#38085666)
    APK's monolithic hosts file is looking pretty good at the moment.
    • lol, +1 funny.

      I'm actually kind of surprised he hasn't stopped by to grace us with his randomly spaced and bolded wealth of knowledge...

    • You can almost hear his hysterical laughter, can't you?
    • by gl4ss (559668)

      I actually went and downloaded a 16k line hosts file and started using that after seeing that post, you know just for trying it out.
      some sites load up faster. I just googled for some file that had been updated last month.

    • by mcavic (2007672)

      monolithic hosts file is looking pretty good at the moment

      Yeah, and when my car runs out of gas I'll just push it wherever I want to go.

  • Like "truly epic coronal mass ejections", lets save the hyperbole for when we can't use it. We'll know that there's a big problem when we can't read about it on Slashdot.
  • Tip of the iceberg (Score:5, Insightful)

    by mseeger (40923) on Thursday November 17, 2011 @11:27AM (#38085950)

    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

    • by kqs (1038910) on Thursday November 17, 2011 @11:42AM (#38086176)

      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.

      • by blair1q (305137)

        The assertion is a problem.

        Deployed code with asserts in it is crap, and would violate any contract I've worked to since 1995.

        At least this was just teh interwebs that it broke. If it had been safety-related, someone would be ducking under their desk trying to call their lawyer.

        • by surgen (1145449)

          The assertion is a problem.

          Deployed code with asserts in it is crap, and would violate any contract I've worked to since 1995.

          At least this was just teh interwebs that it broke. If it had been safety-related, someone would be ducking under their desk trying to call their lawyer.

          So your code, that you make sound more important and/or safety related than DNS, doesn't have any failsafes? Really?

          • by blair1q (305137)

            My code, which sometimes is the difference between life and death, considers all possibilities to be nominal cases, and deals with each equivalence class accordingly.

            People who use asserts in fielded code are either (1) lazy or (2) dumb or (3) cheating their employers.

            • by Chirs (87576)

              People who use asserts in fielded code are either (1) lazy or (2) dumb or (3) cheating their employers.

              Assuming performance isn't a problem, why wouldn't you leave them in on the off chance that you made a mistake in a corner case somewhere?

              • by blair1q (305137)

                The fact that they're even there means you know there's a vulnerability, and you know you don't have a viable way to deal with it, and that your users will, eventually, run into it, probably in a situation where it causes them way more grief than the rest of your code is worth.

                Just using NDEBUG to turn them off is passing the buck to the rest of the code to crash cryptically instead of crashing identifiably, so it's even worse.

  • 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.
    • Re:Open resolvers (Score:5, Insightful)

      by Short Circuit (52384) <mikemol@gmail.com> on Thursday November 17, 2011 @12:07PM (#38086536) Homepage Journal

      More likely, the unusual TXT lookups were someone streaming IP over DNS.

      • by mcavic (2007672)

        someone streaming IP over DNS

        If I owned a gun...

  • How hard is it to write a DNS server without any vulnerabilities? I know it's complex, but still, come on. It's only the backbone of the Internet we're talking about.
    • by blair1q (305137)

      In this case, it's a simple as not using an assert, particularly as an input validator...

      Seriously, are they fucking kidding with that? Do they also hardcode backdoor passwords?

      Grep all your code for assert, and, if they aren't wrapped in #ifdef DEBUG or something similar, replace them with something useful.

    • by psydeshow (154300)

      How hard is it to write a DNS server without any vulnerabilities? I know it's complex, but still, come on. It's only the backbone of the Internet we're talking about.

      The usual suspects: enterprise and legacy. Rather than just being a passive lookup engine, BIND has all kinds of extra interfaces and message-passing schemes that keep secondaries in sync with the master and allow automated processes to update and reload zones semi-automatically. I suspect there are also a bunch of legacy record types and zone file syntaxen that need to be supported.

      It's similar to (but not as bad as) the problem with mail transport agents (MTAs aka SMTP servers). To be feature-complete and

  • It has an atrocious security history. Seems the rewrite did not accomplish much. Or if you have to use it, lock it into a VM, preferably qemu, so that you get at least some level of isolation.

    • by Above (100351) on Thursday November 17, 2011 @07:04PM (#38092156)

      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 [isc.org], listing them all on the web site and registering them with the CVE Registry [mitre.org].

      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 [isc.org], which should be yet another large leap forward.

      • by gweihir (88907)

        Well, as the current problems show, BIND9 still does not get it quite right. I agree that it is better. If BIND10 can make the same step as was made from 4/8 to 9, then BIND10 will finally be a good piece of mission-critical server software. And, yes, that is what is it and has to be. So comparing it to "most other open source projects" is bogus. Not even apache is that critical. Maybe OpenSSH, but it has a truly amazing security record, which certainly is no accident. BIND still has to get there.

        I am not s

        • by Above (100351)

          I'm confused why BIND would be more critical than Apache (to use your example).

          DNS is, from the start, a robust, distributed system. If you have 4-6 name servers for your domain (as you should) and one is down for any reason (network unreachable, server dead, BIND crashed, whatever) users _should not notice_. Caching resolvers will automatically query other name servers, life will move on. Compare with widely used software such as Apache, Sendmail, Firefox, when those fail typically a user notices.

          Indeed

  • by macraig (621737) <mark...a...craig@@@gmail...com> on Thursday November 17, 2011 @02:12PM (#38088362)

    I use TreeWalk. Since it's an implementation of BIND, do I need to apply this patch to it, and if so how?

Bus error -- please leave by the rear door.

Working...