Slashdot Mirror


New DoS Vulnerability In All Versions of BIND 9

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

9 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. 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.

  3. 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.

  4. OMG... by Garion911 · · Score: 5, Interesting

    I reported a bug *very* similar to this back in Oct, and only now its coming to light? WTF? I submitted this back in january and it was rejected. Ah well. Here's my page on it: http://garion.tzo.com/resume/page2/bind.html

    --
    Slashdot is like Playboy: I read it for the articles
  5. Re:Interesting by Minwee · · Score: 5, Funny

    It is now.

    This vulnerability also gives the three people running DJB DNS a much needed opportunity for some smugness.

  6. Re:Interesting by kriebz · · Score: 5, Funny

    I was under the impression they had smugness to spare.

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

  8. Re:All versions of Bind 9? by tygerstripes · · Score: 5, Funny

    But it's a DOS vulnerability!!! Sheesh, read the title...

    --
    Meta will eat itself