Slashdot Mirror

← Back to Stories (view on slashdot.org)

New DoS Vulnerability In All Versions of BIND 9

Posted by kdawson on from the binding-with-briars-my-joys-and-desires dept.

Icemaann writes "ISC is reporting that a new, remotely exploitable vulnerability has been found in all versions of BIND 9. A specially crafted dynamic update packet will make BIND die with an assertion error. There is an exploit in the wild and there are no access control workarounds. Red Hat claims that the exploit does not affect BIND servers that do not allow dynamic updates, but the ISC post refutes that. This is a high-priority vulnerability and DNS operators will want to upgrade BIND to the latest patch level."

16 of 197 comments (clear)

  1. Use Unbound or NSD by nwmcsween · · Score: 5, Informative

    I don't want to bash BIND but it has had a fair amount of sec issues (well a lot), try unbound or nsd instead http://unbound.nlnetlabs.nl/ http://www.nlnetlabs.nl/projects/nsd/

    1. Re:Use Unbound or NSD by medlefsen · · Score: 5, Informative

      or djbdns. We use it where I work and other than a slight adjustment to djb-land it has been wonderful. I know people appreciate how powerful BIND is and maybe some people need that. I suspect though that most people just need their DNS servers to serve their DNS records or provide a caching DNS server for local lookups and for that BIND seems to be bloated and insecure.

  2. Re:Interesting by d3matt · · Score: 2, Informative

    so... any BIND server would be down for a bit... anyone with a caching name server would still be able to surf.

    --
    I am d3matt
  3. Re:Ain't what it used to be.... by ScytheBlade1 · · Score: 4, Informative

    I'm just hoping that CentOS pushes out the update before 10:00 PM MST today.

    Why?

    So I'll get my daily e-mail status update, telling me to do just that: run yum, and then restart (just bind) -- as opposed to seeing it tomorrow.

    As a footnote, it is generally a good thing to subscribe to whichever vendor's security-announce list that you use. It is really nice getting e-mail notifications of security-related package updates. CentOS has one, right here: http://lists.centos.org/mailman/listinfo/centos-announce

  4. Only effective against MASTERS... by Olmy's+Jart · · Score: 5, Informative

    From the advisory: "Receipt of a specially-crafted dynamic update message to a zone for which the server is the master may cause BIND 9 servers to exit. Testing indicates that the attack packet has to be formulated against a zone for which that machine is a master. Launching the attack against slave zones does not trigger the assert."...

    So an obvious workaround is to only expose your slave DNS servers and to not expose your master server to the Internet. That's part of "best common practices" isn't it? You have one master and multiple slaves and you protect that master. Come on, this is pretty simple stuff. Just simple secure DNS practices should mitigate this. Yeah, if you haven't done it that way to begin with, you've got a mess on your hands converting and it's easier to patch. But patch AND fix your configuration.

    1. Re:Only effective against MASTERS... by totally+bogus+dude · · Score: 2, Informative

      As kju responded, you can reload on particular zones if you want. The logs seem to suggest that bind itself only actually reloads the zones which have changed (i.e. mtime is newer than the last time it was loaded). I only get messages that it's loading every zone if I actually restart bind (stop and start), telling it to reload I only get messages about zones that have actually been changed.

      I haven't noticed any performance hit from doing a simple reload, but I only have 120 zones.

      If we were supplying secondary DNS for an (un?)trusted third party then yes I'd use bind's zone transfer mechanism. But we don't so it's not an issue - we only serve DNS for things we host/manage ourselves.

    2. Re:Only effective against MASTERS... by Fastolfe · · Score: 2, Informative

      So I'm responding not because I disagree with your conclusions, but I disagree with the logic you're using to justify them:

      Because lots of people don't want intruders being able to affect the actual zone data in case an outward-facing DNS server gets compromised. ...
      If having a DNS machine on the Internet that thinks it is a master really is a mistake, when then, BIND9 is a piece of shit. This is the most straightforward thing a DNS daemon should be asked to do.

      You start off with a reasonable statement (that you don't generally want compromised DNS servers to allow for the modification of data), but then you say bind9 is a piece of shit because it's a best practice that the masters (which hold the data) shouldn't be exposed to the public. Which is it?

      Using SSH to transfer zone data is much easier and more secure than BIND's own zone transfer mechanisms

      Would you care to elaborate on that? Doesn't TSIG secure zone transfers? TSIG is just as easy to set up as SSH keys are.

      (e.g., you can automate and schedule them)

      How much more automated can you make automatic zone transfers? What better scheduling of zone transfers than when the zones are modified?

      you don't have to worry about zone transfers through firewalls

      The only thing you need to open through the firewall is TCP and UDP port 53. Most firewalls make this easy, because "Serve DNS through the firewall" is a common configuration for firewalls.

      Troubleshooting all the weird crap that can happen between different DNS daemons all supposedly doing regular AXFRs is a real pain in the ass. SSH makes life easier.

      SSH makes life easier for someone that understands SSH, and does not understand DNS or firewalls.

      That being said, there are valid reasons you might not prefer to run a DNS master as the source for your slaves/shadow masters, and SSH might even be a good way to push your zone files out to those machines, but you have not provided any of those reasons.

  5. Re:At least someone agrees that BIND 9 had issues. by profplump · · Score: 5, Informative

    Recent versions of BIND (8+) are not terrible to administer, and have much more reasonable data files. Older version were *really* nasty, and had a data file format so complicated that we invented a dedicated zone-transfer mechanism just so people could send DNS data to each other.

    And while djbdns uses an unconventional admin system with lots of environmental variables, that's a one-time setup (that is probably done in large part by your package manager) and the actual data files are dead-simple -- plain text, one record per line, can do DNS lookups at build time, can concatenate files, etc. There are valid complaints to be made about djbdns, but I don't think "difficult to wrangle" is one of them.

  6. No need to restart bind after updating using yum by dusanv · · Score: 2, Informative

    It gets restarted automatically. Check system.log.

  7. Re:At least someone agrees that BIND 9 had issues. by Anonymous Coward · · Score: 1, Informative

    Recent versions of BIND (8+) are not terrible to administer

    Try configuring dynamic DNS through nsupdate with a shared secret.

    If you have an NS key, you can specify the key on the command line, or you can store the key in a file, and pass the filename.

    The former is a security risk (as anyone running 'ps' can see your key). The latter? Well, someone decided that it would be a good idea to hard code metadata in the filename (even though the same metadata must be present inside the file too.) Oh, and you need two files, even though it's only using one. Oh, and you need to name the key the same as the zone in your named.conf.

    Considering that I've only ever seen that level of idiocy from first year comp-sci majors, I have to wonder at the technical competence of the people in charge of writing BIND.

  8. Re:Ain't what it used to be.... by secolactico · · Score: 3, Informative

    You seem to be just taking all changes and rebooting. I do that all the time on my ubuntu laptops but I wouldn't manage my servers that way.

    More so because some package managers (such as CentOS) tend to replace customized init.d files with the stock ones (renaming the ones you had). This is not really a big deal, but it sometimes breaks some services.

    --
    No sig
  9. iptables to the rescue by kju · · Score: 5, Informative

    For a quick "fix":

    iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5'

    Will block (all) dnsupdate requests.

  10. Re:djb by Anonymous Coward · · Score: 1, Informative

    None of that changes the fact that his software is several orders of magnitude more secure than the competition.

    Him being an asshole doesn't change any of that and the constant harping on about it smacks of resentment and an inferiority complex.

  11. Re:At least someone agrees that BIND 9 had issues. by rs79 · · Score: 2, Informative

    " Older version were *really* nasty, and had a data file format so complicated... "

    Rememeber that this was a product of the early 1980s; Brian Reid, Director of Digital Equipment Corporation's Network Systems Laboratory ("decwrl.uucp") hired a kid, Paul Vixie, to take the buggy Berkley B-tree code and turn it into something resembling professional software. At the time even C was not even close to ubiquitous, Assembler was though and in fact the great majority of code written for the early microprocessor based systems of that era was written in assembly.

    So it should not be any great shock that bind config files looked like assembly code, or that the later versions looked like C.

    Frankly I found the earlier bind config files much easier to use, and the djbdns config files even easier (once you get used to them) to use, and (much) more importantly, you can write a program to manipulate these datum very easily. It's ugly and complicated with bind data files of any version.

    --
    Need Mercedes parts ?
  12. Re:god they should learn programming by rolfc · · Score: 2, Informative

    I am already updated. Thanks to Debian.

  13. Re:Ain't what it used to be.... by Anonymous Coward · · Score: 1, Informative

    Still works, according to shutdown(8) on CentOS.

    -r : reboot
    -f : skip fsck
    -n : don't go through init, just kill everything

    Would be a pretty fast way of rebooting, especially if you have lots of slot K* scripts in /etc/init.d/*

    It's not recommended, though, because you never know how much "just kill everything" is going to destroy... Corrupt files, etc.