Slashdot Mirror


Critical BIND Denial-of-Service Flaw Could Take Down DNS Servers

alphadogg writes: Attackers could exploit a new vulnerability in BIND, the most popular Domain Name System (DNS) server software, to disrupt the Internet for many users. The vulnerability affects all versions of BIND 9, from BIND 9.1.0 to BIND 9.10.2-P2, and can be exploited to crash DNS servers that are powered by the software. The vulnerability announced and patched by the Internet Systems Consortium is critical because it can be used to crash both authoritative and recursive DNS servers with a single packet.

31 of 68 comments (clear)

  1. Patched on 7/28 (CentOS) by bill_mcgonigle · · Score: 5, Informative

    I noticed this on Google News yesterday - checked a CentOS 7 box to find that yum had installed the patch overnight on 7/28 and systemd had restarted named for me. Good work, everybody. Make sure your updates are working.
    Oh, hai dollar-short Slashdot.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    1. Re:Patched on 7/28 (CentOS) by unrtst · · Score: 3, Informative

      FWIW, it seems CentOS 6 was not updated (though there is an SRPM from RHEL for it).
      CentOS 5 and 7 both have the update. Example mirror:
      http://mirror.atlanticmetro.ne...
      http://mirror.atlanticmetro.ne...
      http://mirror.atlanticmetro.ne...

      I also checked the mirror status: http://mirror-status.centos.or...
      And checked one that was JUST updated: http://mirror.millry.co/CentOS...
      No update!!!

      RHEL page on their 6.x update: https://rhn.redhat.com/errata/...

    2. Re:Patched on 7/28 (CentOS) by whoever57 · · Score: 1

      FWIW, it seems CentOS 6 was not updated (though there is an SRPM from RHEL for it). CentOS 5 and 7 both have the update. Example mirror:

      I think it will be in 6.7, which is being prepared for release now.

      --
      The real "Libtards" are the Libertarians!
    3. Re:Patched on 7/28 (CentOS) by IAN · · Score: 1

      FWIW, it seems CentOS 6 was not updated (though there is an SRPM from RHEL for it).

      The update is in the CR repo because of the preparations for the release of CentOS 6.7. Short explanation here (with the link to the page explaining how to enable the additional repo), and a couple of longer explanations further down the thread.

  2. Interesting, but budgie cage liner news by Demonoid-Penguin · · Score: 3, Informative

    Patched updates rolled out long before /. reported it (shock, horror).
    If Debian is any guide most distros have already done the same and anyone running unattended-updates for security patches has been updated for several days (25th).

    1. Re: Interesting, but budgie cage liner news by therealkevinkretz · · Score: 2

      ... Not opensuse

    2. Re: Interesting, but budgie cage liner news by rubycodez · · Score: 3, Informative
    3. Re: Interesting, but budgie cage liner news by Demonoid-Penguin · · Score: 1

      ... Not opensuse

      As another poster has already pointed out - that's incorrect.

      But interesting anyway. Maybe Open SUSE is just a little slow because of a trickle-down from SUSE? Regardless of the reason you might consider subscribing to the opensuse-security-announce mailing list.

      . At least you don't have to wait until Patch Tuesday.

    4. Re: Interesting, but budgie cage liner news by therealkevinkretz · · Score: 1

      Yeah, I saw that too. It was reported then, but a patched BIND wasn't available from opensuse until Monday 8/3.

  3. .GOV knew on the 28th, com'on, old news by Anonymous Coward · · Score: 1

    The US Gov knew and published this on the 28th. Way to be 3 days late, an no doubt why /. is more than a dollar short.

    https://www.us-cert.gov/ncas/current-activity

    1. Re:.GOV knew on the 28th, com'on, old news by Demonoid-Penguin · · Score: 1

      The US Gov knew and published this on the 28th. Way to be 3 days late, an no doubt why /. is more than a dollar short.

      https://www.us-cert.gov/ncas/current-activity

      The "government" is proactive!. Cool.

      Soon we'll all have flying cars for sure (or, flying SUVs with in-dash McD snack printers and heavy-duty conveyor belts in place of door-steps).

  4. Re:Just goes to show you UNIX SUX by Cramer · · Score: 1

    Fine. You go write a DNS server and see how horribly bug your shit is. (hint: DNS is a *complicated* protocol)

  5. Re:Windows by Demonoid-Penguin · · Score: 1

    Now imagine if Windows had done the same thing. Slashdot would be in an uproar.

    First I need to imagine it's that Tuesday of the month. [shuts eyes] Nope, doesn't work (maybe it's the same with wishful "thunking"?).

  6. Re: Just goes to show you UNIX SUX by Demonoid-Penguin · · Score: 1

    No it isn't... it's one of the oldest and simplest protocols around you freetard. And the fact that BIND still has exploitable bugs on a protocol that is decades old shows how terrible freetard are at programming.

    *cough* That coward was being ironic. Whether it was intentional or not is beside the point. It was nice satire too.

    You'd think the version number might be a clue. Oh wait... this is /. The entrance requirement is an internet connection and a keyboard.

    Instituting one of those simple math question robot checks would double the signal:noise ratio - and reduce the advertising revenue by 70% (I'm allowing for the adblock users).

  7. Re:DNS is for Luddites. by Anonymous Coward · · Score: 1

    I want to block you guys with a hosts file entry. Hosts file entries are for APK. AAAAAAAAPPPPPPPPKKKKKKKK!

  8. Re:We need to use Rust NOW! by Narcocide · · Score: 1

    You guys are fucking hilarious.

  9. Re:The timing of this is interesting by Narcocide · · Score: 1
  10. Re: Just goes to show you UNIX SUX by dgatwood · · Score: 1

    Actually, it's not that simple. The DNS compression scheme is horrendous, although that can be easily isolated. Most of the complexity of DNS servers come from the 1) caching, recursive logic for client-side servers, 2) automating zone transfers, 2) various schemes for avoiding DoS attacks. Dedicated servers like NSD and unbound, which either server a zone _or_ implement recursive lookups for clients, can be a little simpler.

    I've never understood why DNS servers bother with zone transfers. These days, it would take an average admin three minutes to toss together something involving a cron job, rsync, and ssh that would do the same job without adding all that extra code and the extra attack surface that comes along with it. Heck, with access to platform-specific file system event APIs, you could probably come up with something that worked a lot better, up to and including near-instantaneous updates. That entire feature just seems like pure bloat, and that's coming from somebody who actually uses zone transfers....

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.

  11. stfu troll by drinkypoo · · Score: 1

    Now imagine if Windows had done the same thing. Slashdot would be in an uproar.

    Bullshit, stop trolling. When Microsoft releases a patch which doesn't break anything, nobody complains. It's when they release "patches" which alter the behavior of the operating system in undesirable ways that we get our knickers twisted.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  12. Re: Just goes to show you UNIX SUX by drinkypoo · · Score: 1

    I've never understood why DNS servers bother with zone transfers.

    Yes, and many people disable them, and some DNS servers don't even have the functionality.

    Heck, with access to platform-specific file system event APIs, you could probably come up with something that worked a lot better, up to and including near-instantaneous updates.

    Well, obviously if you have a system of any complexity, you should be stuffing the records into a database and then generating the zone files from that. You can handle your replication at that level. Give your serial numbers meaning (As a timestamp, typically) to avoid issues there.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  13. But not patched in CentOS 6.6 by terremoto · · Score: 2

    A heads up for those running CentOS 6.6. This issue is not patched by default (because CentOS is in the midst of the transition from 6.6 to 6.7). Sysadmins using bog-standard CentOS 6.6 bind will need to enable the continuous release (CR) repository and update bind using that.

    See the CentOS 6 Security Support forum post CVE-2015-5477 patch for centos 6

    Wondering if this issue is serious enough to warrant the CentOS folk putting some patched bind rpms in the CentOS 6.6 updates repo? My guess is that a lot of people might miss the patch otherwise.

  14. How long has it been? by tlhIngan · · Score: 2

    Don't you just long for the days when sendmail and bind would be always in the news because of some flaw or other? Heck, didn't we all run alternatives because sendmail and bind were so buggy...

    How long has it been since we last had a Bind security issue...

    1. Re:How long has it been? by OrangeTide · · Score: 2

      How long has it been since we last had a Bind security issue...

      Not long enough.

      --
      “Common sense is not so common.” — Voltaire
  15. Re: Just goes to show you UNIX SUX by buchanmilne · · Score: 1

    "I've never understood why DNS servers bother with zone transfers. These days, it would take an average admin three minutes to toss together something involving a cron job, rsync, and ssh"

    So if you are an ISP providing a secondary DNS service, you're happy to create accounts with ssh/rsync access for 10 000 customers who all have more lax security than you do?

    Talk about attack surface ... (even with forced command etc.).

    That said, assuning the complexity isn't in serving thr afxr requests, I see no reason why the function to retrieve the zone needs to be inside the daemon listening on port 53. Of course it would need to trigger transfers based on notifies, but that could be done quite easily (a simple file or a named socket).

  16. Re:Just goes to show you UNIX SUX by fredan · · Score: 1

    That's why I'm writing my own. Nope, I'm not kidding. It's called fDns and will probably be the fastest authority DNS server there is.

  17. Re: Just goes to show you UNIX SUX by fredan · · Score: 1

    I'm using C with LMDB. Think of it as Tinydns on steroids. With Lua.

  18. Upgrade to CR ... by Anonymous Coward · · Score: 1

    Right, it's because Centos 6.7 hasn't been released yet and Red Hat has't made upgrade for RHEL 6.6.

    Thus if you had RHEL 6.6 and hadn't yet upgraded 6.7 you would have same situation.

    But, fortunately there is a solution available, which you may choose to take. Upgrade to continuous release version and get upgrades from there before official point release is available.

    What you need to do is simply

    # yum install centos-release-cr

    Make sure you have enough free space available for several hundred packaces (/var/cache/yum/) and doing 6.6 to CR-upgrade which is quite close to 6.7, then

    # yum clean all
    # yum upgrade

    Then it's probably a good idea to boot after that, too get new kernel etc. stuff

    Cheers,

    ac

    This kind of information is usually avalable from the mailing list & archives of the list for the release you use, as the case here too. There you have answer , check the thread and read CR wiki page pointed from that answer, please.

  19. Re:God Damn It, Bind... by amorsen · · Score: 1

    Bind has been rewritten practically from scratch multiple times. This has strangely not helped security as much as one would hope...

    To be fair, at least they are mostly DoS bugs, not root-in-one-packet like in the good old days. At least we hope they are.

    --
    Finally! A year of moderation! Ready for 2019?
  20. Re: Just goes to show you UNIX SUX by dgatwood · · Score: 1

    So if you are an ISP providing a secondary DNS service, you're happy to create accounts with ssh/rsync access for 10 000 customers who all have more lax security than you do?

    Sure. You give them all a shell account with access to their own zone files, and you require them to provide a public key for authentication (no passwords to attack). Then, you have a separate process that watches for changes and updates the official zone files that the daemon reads. Clearly, a daemon that has write access to all of the zone files is inherently less safe than a series of ssh accounts, each with access to only a single user's files, coupled with a daemon that has only read-only access to copies of the original zone files.

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.

  21. Re:We need to use Rust NOW! by iggymanz · · Score: 1

    :LISP can build, index, update and use GIANT HOSTS FILES

    You lose! Grovel like a worm before the Queen of Programming Languages(TM)!!

  22. Re: Just goes to show you UNIX SUX by dgatwood · · Score: 1

    I'm not forgetting. Then again, that was also true for telnet back when I started setting up DNS zone transfers.... Just saying. :-)

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.