Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security The Internet

High Severity BIND Vulnerability Advisory Issued 144

Posted by CmdrTaco from the put-on-your-hard-hat dept.
wiredmikey writes "The Internet Systems Consortium (ISC) and US-CERT have issued a high severity vulnerability warning, discovered by Neustar, which affects BIND, the most widely used DNS software on the Internet. Successful exploitation could enable attacker to cause Bind servers to stop processing all requests. According to the disclosure, 'When an authoritative server processes a successful IXFR transfer or a dynamic update, there is a small window of time during which the IXFR/update coupled with a query may cause a deadlock to occur. This deadlock will cause the server to stop processing all requests. A high query rate and/or a high update rate will increase the probability of this condition.'"
This discussion has been archived. No new comments can be posted.

High Severity BIND Vulnerability Advisory Issued More

High Severity BIND Vulnerability Advisory Issued

Comments Filter:

  • latest BIND not affected (Score:5, Informative)

    by doperative ( 1958782 ) on Wednesday February 23, 2011 @10:19AM (#35290324)

    "There have been no active exploits known, and versions 9.7.1-9.7.2-P3 versions of BIND are affected. US-CERT encourages users and administrators using the affected versions of BIND to upgrade to BIND 9.7.3 "

    • Re:latest BIND not affected (Score:4, Informative)

      by Bacon Bits ( 926911 ) on Wednesday February 23, 2011 @11:30AM (#35290992)

      That's because the latest BIND was released specifically to patch this vulnerability. They just didn't really tell anybody about the vulnerability until after 9.7.3 was released. Don't believe me?

      CERT was notified at the end of January.
      "Date Notified: 2011-01-24" [ http://www.kb.cert.org/vuls/id/559980 [cert.org] ]

      The CVE was reserved in the middle of January.
      "Assigned (20110111)" [ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0414 [mitre.org] ]

      Yet the release notes for 9.7.3 don't mention any fixes which would coincide with this vulnerability:
      http://ftp.isc.org/isc/bind9/9.7.3/RELEASE-NOTES-BIND-9.7.3.html [isc.org]

      Thanks, ISC, for patching a vulnerability a month after you found out about it and then telling us two weeks later that you did that. That's awesome security procedure there.

      • Re:latest BIND not affected (Score:5, Informative)

        by Ethanol ( 176321 ) on Wednesday February 23, 2011 @12:14PM (#35291416)

        That's because the latest BIND was released specifically to patch this vulnerability. They just didn't really tell anybody about the vulnerability until after 9.7.3 was released.

        That's not correct. The locking bug had already been fixed in 9.7.3b1, a month before it was found to be exploitable as a DoS. When we did find that out, we consulted with vendors and decided to continue with the releases in progress.

        • I see, it was originally just a locking bug. That makes it easier to find a likely candidate in the Release Notes:
          "Corrected a defect where a combination of dynamic updates and zone transfers incorrectly locked the in-memory zone database, causing named to freeze. [RT #22614]"

          Even if I do believe you, why did you wait so long to notify the community of the DoS vulnerability?

          • Re: (Score:3, Informative)

            by Anonymous Coward

            We notified our forum members as soon as we understood the full scope of the issue, key operators/vendors the next day, and the general community one week later, as per our Security Disclosure Policy: http://www.isc.org/security-vulnerability-disclosure-policy.

            • Sorry, that was me, Larissa Shapiro, ISC product manager.

              • Re: (Score:2, Insightful)

                by Anonymous Coward

                So, BaconBits - are you going to publicly retract your statements impugning BIND's process?

                You made some very harsh judgement, evidently without any research into backup said accusations - IMO, you owe an apology. [I'm posting AC since I don't want to be attacked publicly either, but I have NO association with BIND or any Linux development at all. I'm simply one who uses BIND and Linux servers. Really, I'm just a sysadmin.]

                • Re: (Score:2)

                  by jon3k ( 691256 )
                  You really need a public apology from a guy named "BaconBits" in the slashdot comments section? I wouldn't wipe my ass with a printout of his comment history. I think we can all just move on.

        • Re: (Score:2)

          by jthill ( 303417 )
          It can't be easy to provoke, was the bug found by audit?

      • Re:latest BIND not affected (Score:5, Insightful)

        by pclminion ( 145572 ) on Wednesday February 23, 2011 @01:39PM (#35292278)

        Thanks, ISC, for patching a vulnerability a month after you found out about it and then telling us two weeks later that you did that

        You know, I'm really tired of people who obviously don't write code saying crap like this. Fixing a subtle deadlock could quite realistically take a month. First, you need to figure out really why it happens. Then you need to figure out the CORRECT way to fix it, then you need to implement the fix, then you need to TEST the thing to make sure you didn't introduce anything ELSE that could cause a problem. If the bug was in an easy area of code, chances are it would have been found and fixed a long time ago. BIND has been around a long, long time. Anything left in there now is, by definition, hard to find and hard to fix.

        Look folks, security bugs happen BECAUSE people whip out code without thinking and without testing. Now you ask for them to do exactly that? You need to get a grip on reality.

        • Re: (Score:1)

          by afabbro ( 33948 )

          You know, I'm really tired of people who obviously don't write code saying crap like this. Fixing a subtle deadlock could quite realistically take a month. First, you need to figure out really why it happens. Then you need to figure out the CORRECT way to fix it, then you need to implement the fix, then you need to TEST the thing to make sure you didn't introduce anything ELSE that could cause a problem. If the bug was in an easy area of code, chances are it would have been found and fixed a long time ago. BIND has been around a long, long time. Anything left in there now is, by definition, hard to find and hard to fix. Look folks, security bugs happen BECAUSE people whip out code without thinking and without testing. Now you ask for them to do exactly that? You need to get a grip on reality.

          Just as you need to get a grip on your CAPS LOCK key.

        • Re: (Score:2)

          by Mashiki ( 184564 )

          But...but...
          Reality she's a harsh mistress. I don't like harsh...

        • As a sysadmin I don't care about the timeliness of the fix as much as the timeliness of the disclosure. I care that nobody said anything about it so I couldn't mitigate the risk or be aware of the problem. They knew about it for six weeks and said nothing. Why? They released a new version that fixed the issue, and *still* didn't say anything for two weeks. ISC itself rated the vulnerability severity as "High". Is this how you should handle a high severity vulnerability?

          It's not "OMG where is the fix."

          • Re:latest BIND not affected (Score:4, Insightful)

            by thogard ( 43403 ) on Wednesday February 23, 2011 @05:52PM (#35294750) Homepage

            Keep in mind that ISC runs a lot of very large name servers all over the world that are under constant DDOS attacks and they didn't see this in the wild. At this point, its a theoretical attack and there is a theatrical work around. Releasing the info too soon could have resulted in a real attack against a theatrical work around. I think they did the right thing considering if you had a DDOS problem, you can ask in a number of places and they would have told to you to try the work around.

            • its a theoretical attack and there is a theatrical work around

              Presumably (hopefully?) involving Natalie Portman and hot grits..?

            • Yes, when my systems are experiencing problems the first thing I think of doing is asking the developers if they have any workarounds for undisclosed vulnerabilities that would address my issue.

      • > That's because the latest BIND was released specifically to patch this vulnerability. They just didn't really tell anybody about the vulnerability until after 9.7.3 was released. Don't believe me?

        Except they posted it on a publically accessable list ...

  • I wonder how long it'll be until FreeBSD rolls a security update out for this.

    • Re: (Score:1)

      by Anonymous Coward

      It's OK, most FreeBSD users are not vulnerable, the current production release (8.1) uses bind 9.6.2, which is from before the vulnerability was introduced in the 9.7 series.

      Only users who have independently installed the 9.7 package will have an issue.

  • Earlier versions? (Score:3)

    by psyclone ( 187154 ) on Wednesday February 23, 2011 @10:48AM (#35290588)

    What about versions before 9.7.1? Looks like this vulnerability affects only Bind servers within the specific range: 9.7.1-9.7.2-P3

  • Let me ask a question, when alerts come out like this that explain a vulnerability, do they always state the problem the way it happens?

    Like, if someone understood how to exploit this vulnerability, are they really going to shut down DNS services or could it be that there is a worse vulnerability underneath? For instance, could this actually be a call to patch something that allows for DNS spoof, where someone does not want the issue to have wide awareness?

    • Re: (Score:3)

      by vlm ( 69642 )

      Let me ask a question, when alerts come out like this that explain a vulnerability, do they always state the problem the way it happens?

      Thankfully, yes, err, well, as far as they know at that time. I don't do IXFR on my authoritative or resolving bind servers so I simply don't care. Kind of hard to cause a deadlock during a tiny slice of a time in a process I don't run...

      Like, if someone understood how to exploit this vulnerability, are they really going to shut down DNS services or could it be that there is a worse vulnerability underneath? For instance, could this actually be a call to patch something that allows for DNS spoof, where someone does not want the issue to have wide awareness?

      Uh, no. At least not directly. According to

      http://www.isc.org/software/bind/advisories/cve-2011-0414 [isc.org]

      the server simply stops responding. Usually deadlocks in any software freeze it up quite well rather than false data. Old data, maybe, at worst...

      What happens to the re

  • not "high severity" (Score:5, Informative)

    by Lord Ender ( 156273 ) on Wednesday February 23, 2011 @11:08AM (#35290818) Homepage

    This sounds like a denial-of-service flaw. Such flaws are considered "low severity" in all but the rarest cases. A high-severity flaw would be one which either gives a hacker control of a service or access to sensitive information.

    This is just one more in a long list of well-known ways anyone could knock a server offline.

    • Re:not "high severity" (Score:5, Insightful)

      by Leebert ( 1694 ) * on Wednesday February 23, 2011 @11:41AM (#35291076)

      This sounds like a denial-of-service flaw. Such flaws are considered "low severity" in all but the rarest cases. A high-severity flaw would be one which either gives a hacker control of a service or access to sensitive information.

      It depends entirely upon the requirements for availability. I agree that generally the A in the CIA triad is the least important, but not by any means always.

      Imagine if this could be easily leveraged to shut down all DNS resolvers for, say, all of Comcast. Wouldn't you agree that it's probably a greater impact than, say, a single unimportant desktop somewhere in marketing being compromised by the Flash Of The Day vulnerability?

      Thus is the black magic of IT risk management. :)

      That said, my first thought when reading this headline was the same as yours.

      • Re: (Score:2)

        by vlm ( 69642 )

        Imagine if this could be easily leveraged to shut down all DNS resolvers for, say, all of Comcast.

        Why would your resolvers every do an IXFR? That takes quite an imagination. Now your secondary authoritative servers might be knocked out if they allow IXFRs in addition to the "traditional" AXFR zone transfers.

        • Re: (Score:2)

          by Leebert ( 1694 ) *

          "Imagine if". I was using a hypothetical to demonstrate a completely different point.

      • "High" and "Low" are relative. A high severity DNS flaw would be one that allows attackers to redirect all banking websites to a site they control, as an example. A low severity DNS flaw would be one that makes things not work for a little bit. Any botnet operator could take a DNS server offline anyway, with or without a flow. Low severity.

        • Re: (Score:2)

          by Leebert ( 1694 ) *

          "High" and "Low" are relative. A high severity DNS flaw would be...

          With due respect to your tenure at Slashdot, I believe you're oversimplifying it, or at least not applying common risk management methodology.

          Generally, when assessing the impact of a vulnerability, you're going to assess its impact to each of the three components of the security triad.

          We admin/security types do generally consider impact to availability as being less of an issue, but my point is that it is situation dependent. The fact is, though, that this particular vulnerability (I believe, I haven't RT

          • With due respect to your tenure at Slashdot

            [Facepalm] Clearly, you're just a troll with a silly statement like that. Of course, this should be obvious to anyone reading by now, but your responses are really just pedantic, pointless puffery. Broadly speaking, DoS flaws are low severity. And since this is a broad forum, "broadly speaking" is all we can reasonably hope for. We in the security world know that individual circumstances vary. That is so obvious that it goes without saying. So don't expect to get a

            • Re: (Score:3)

              by Leebert ( 1694 ) *

              Clearly, you're just a troll with a silly statement like that.

              No sir, my intention was to be disengaging by acknowledging that I was aware that I was talking to a person who probably would generally understand the principles about which I was speaking. I *do* recognize usernames on slashdot, and try my best to acknowledge people who have been around for a long time and generally contribute positively toward the discussion.

              your responses are really just pedantic, pointless puffery. Broadly speaking, DoS flaws are low severity.

              Then please, by all means, refute it with something other than assertions. Show me how a network-based, low access complexity, non-authenticated v

    • http://www.kb.cert.org/vuls/id/559980 [cert.org]
      Severity metric: 4.50 (on a scale from 0 to 180)

      Sounds like not very high to me either, lol.

      That said, it's a kinda serious vulnerability given that the Internet relies a lot on DNS and many servers are running BIND.

      Then again, we should be running at least DNSSEC by now, and not provided by BIND, right? right?!

    • The ISC and US-CERT have it ranked as "High Severity"

    • When you put the vulnerability into a CVSS calculator you get a score of 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C) which is in the high range.
      Yes, CVSS isn't perfect but that is what is being used. About the only wiggle room is on access complexity even that may be deemed low.
      This is a race until you win attack.

  • not high severity (Score:3)

    by Lord Ender ( 156273 ) on Wednesday February 23, 2011 @11:14AM (#35290858) Homepage

    High severity threats are those that either disclose sensitive information or allow unauthorized control of a service or system. Denial of service vulnerabilities are almost universally considered low severity. This is just one more in a long list of known ways to DoS a system.

    • I don't know why the article does not link to the original advisory [isc.org] but the ISC qualified this vulnerability with a severity level high.

      • That's true, but the CERT advisory only lists the severity metric as 4.5. That's not out of 10. It's out of 180.
        http://www.kb.cert.org/vuls/id/559980 [cert.org]

        ISC very well may use a different ranking scheme for vulnerabilities. DNS is required to have high availability, and this would severely impact that. ISC may rate it highly simply because the common usage scenarios for BIND make this more concerning.

      • Assantisz, the article does link to the ISC advisory. Are you are correct, they do list it as high severity.

    • http://tech.slashdot.org/comments.pl?sid=2008894&cid=35290818

      DONT DO DAT

      • Yes, I posted twice. But only because slashdot had an outage during which comments were not showing up. Apparently slashdot was queuing up posts but not displaying them until later for a while earlier today. Don't blame me for slashdot's bug.

  • Wow. (Score:2)

    by DavidTC ( 10147 )

    Who could have foreseen such a problem in such modern and well-crafted software.

  • Neverbind the summary (Score:1)

    by Anonymous Coward

    This was bound to happen...

  • djbdns [cr.yp.to] - if you want a secure one.

    • if you want a secure one.

      If you want it to be really secure, you'd just turn the server off. If you want secure and functional, isn't even an option.

      I'll say it: djbdns is the least secure popular DNS daemon. Its fatal flaw is that it only implements the easiest parts of DNS. Maybe it's exceedingly secure at handling that stuff. Who knows? Who cares? It leaves all the hard part of DNS administration to be re-implemented at every single site. For example, to the best of my knowledge, djbdns still doesn't implement IXFRs. The securit

      • Hey, you need interesting? You got it. It's this story.

        My server is not interesting. It's boring like a fuck.

      • What a load of bullshit.

        I don't know about you, I just want to sleep at night not worrying about any exploit du jour, and that definitely includes BIND.

        Let me tell you how to update djbdns fast:

        1. ssh to your slave.
        2. scp your 'data' file.
        3. run 'make'

        You're seriously going to be a BIND apologist because you can't take 30 seconds to ssh/scp a file?

        If you find yourself making DNS changes so often that this is a problem, take the time to automate it and focus on what you're doing, not going down some shit-ha

        • If you find yourself making DNS changes so often that this is a problem, take the time to automate it and focus on what you're doing, not going down some shit-happy path towards Kerberos enlightenment. Or figure out why you have to keep changing DNS records so often and come up with a better method.

          Perhaps you've heard of IPv6 (DJB hasn't, but maybe you're quicker on the uptake)? Suppose you run a company with 10,000 desktops and servers, all neatly categorized and named in your IPv4 DNS zones. Now you've decided to roll out IPv6 on that same network, and want each host's name to resolve with an A record and an AAAA record. The easiest way to do that is to let each machine update DNS with its own hostname and IP - subject to the proper restrictions. Move a machine to a different subnet? No problem: it

          • Perhaps you've heard of IPv6 [snip]

            Perhaps you've heard of turd polishing?

            Find something that supports IPv6 that isn't a security nightmare. They exist. Isn't that your job as a netadmin, anyway? It's because of lazy-assed admins that keep following turds like BIND -- religiously -- that it remains #1 in market share when it should have been kicked to the curb long ago for being the bloated, slow dog that it is.

            And I think I've already made my point about the relative easy[sic] [snip]

            Security isn't always easy. You've made your deal with devil. Tell me all about it when he calls the tune and your BIND box get

      • Re: (Score:2)

        by thogard ( 43403 )

        The most interesting bit with the whole 'X is more secure and the old dinosaur programs" is that most of the new rewrites have the same deadlock or race conditions but they never get fixed. Sendmail and bind have plenty of OS work arounds in their code because they are needed to keep the whole system secure.

        • The most interesting bit with the whole 'X is more secure and the old dinosaur programs" is that most of the new rewrites have the same deadlock or race conditions but they never get fixed. Sendmail and bind have plenty of OS work arounds in their code because they are needed to keep the whole system secure.

          Joel Spolsky (the "Joel on Software" guy) advocates never throwing out the code and starting from scratch. Perhaps that's true in most cases, but not with BIND and any BIND derivatives.

          IIRC the ISC tried that with BIND 9. Supposedly a rewrite, but I've read opinions that they imported a lot of the old code anyway. It doesn't really matter.

          Sometimes you have to lose the old mindset and start with fresh eyes and a new attitude. Go back to basics and follow the KISS rule. DJB, whether you like him or not,

      • Why are you so mad at DJB or djbdns?

        djbdns comes with AXFR tools, maybe you hadn't heard? And really, using rsync and SSH aren't that hard?

        Anyway, I think a lot of people are happy with "uninteresting" DNS. It's functional enough, it seems: http://mydns.bboy.net./survey/ [mydns.bboy.net]

  • Does anyone know which DNS servers are either derived from or just repackaged BIND? I haven't been able to find this information anywhere.

  • (reference https://www.isc.org/software/bind/advisories/cve-2011-0414 [isc.org])

    * As Larissa pointed out, this security advisory used ISC's phased disclosure process (see http://www.isc.org/security-vulnerability-disclosure-policy [isc.org]). The US CERT advisory stated they notified ISC on 2011-01-24. This is reversed. US CERT and all other National CSIRT Teams were notified at the same time (Feb 15th). We just recently added the step in our disclosure process to notify all National CSIRT Teams listed on first.org.

    * US-

Slashdot Top Deals

It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.

Close