Forgot your password?
typodupeerror
Security

Bind 4 and 8 Vulnerabilities 408

Posted by michael
from the who-uses-BIND4-anymore dept.
eecue writes "The world's most popular DNS package is once again vulnerable. Even the advisory says it's only a matter of time before worms are written.... just like a couple years ago. I guess this is why i run tinydns."
This discussion has been archived. No new comments can be posted.

Bind 4 and 8 Vulnerabilities

Comments Filter:
  • Escape (Score:5, Informative)

    by Borodimer (201221) on Tuesday November 12, 2002 @03:12PM (#4652925) Homepage
    Escape your binds, use djbdns.
    • Re:Escape (Score:5, Funny)

      by Anonymous Coward on Tuesday November 12, 2002 @03:27PM (#4653094)
      Escape your need for functionality, well-documented behaviors and the ability to freely import and export zone data without being a 15th-century sorcerer.
    • Re:Escape (Score:2, Insightful)

      This is why [linuxmafia.com] running BIND9 instead of the djb stuff may be a very good idea.
      • Re:Escape (Score:3, Informative)

        by Anonymous Coward
        The linuxmafia article is also wrong on several counts.

        If you own a piece of copyrighted work, you can alter it for your own use legally. Try this. Pick up the newspaper, and put a mustache on GW Bush. It is legal !!!

        Now, for software, the same conditions hold. Download djbdns. Add the comment /* djb is a quirky dude */ to the source and compile it. ALSO COMPLETELY LEGAL !

        Omigod. What a revelation.

        Anyway, the main barrier placed up by djb is that it would be tough to port djbdns to a non-UNIXlike OS, and tough for a distro to carry it (since the distro will need to distribute the source, potentially a patch, and have it build on install). Debian DOES distribute qmail. And a patch, and it builds on install. You are definitely given EXPLICIT permission by djb to distribute the latest source tarballs that are accessible on his website.

        As far as the other stuff, well, a large patch community is built around qmail and tinydns, and DJB is quite supportive. You get the source, and the ability to change it for personal use. And the ability to distribute patches to the source. Isn't that enough ?
        • Re:Escape (Score:4, Informative)

          by rickmoen (1322) <rick@linuxmafia.com> on Tuesday November 12, 2002 @05:55PM (#4654395) Homepage
          An anonymous coward wrote:

          The linuxmafia article is also wrong on several counts.

          Please let me know, and I'll fix them.

          If you own a piece of copyrighted work, you can alter it for your own use legally.

          John Cowan's analysis on license-discuss@opensource.org of the USA Copyright Act's legislative history suggests that modification is not among the rights automatically conveyed. The essay on my site links to a mirror of his analysis, so you're welcome to evaluate its merits for yourself. My only comment was that Cowan "convincingly disputed" Prof. Bernstein's assertion to the contrary. But whether you'll be similarly convinced is entirely between you, Cowan, and the legislative record.

          You claim that there my essay is "wrong on several counts", but only cite only one particular on which you seem to disagree (without clearly stating why, other than that handwave about newspapers) -- not with me, but rather John Cowan. Are there other points, that you accidentally neglected to include? Please do detail them, when you have a chance.

          As far as the other stuff, well, a large patch community is built around qmail and tinydns, and DJB is quite supportive. You get the source, and the ability to change it for personal use. And the ability to distribute patches to the source. Isn't that enough?

          It's very generous, and commendable of Prof. Bernstein to grant that to the user community. In fact, it's about as generous as it's possible to be with proprietary software. Anyone who's content to become dependent on proprietary software might be very pleased with djbdns, qmail, tcpserver, publicfile, daemontools, and other similar proprietary-licensed offerings -- if they like the design (which I happen not to).

          Funny how proponents of DJBware just seem completely unable to utter the word "proprietary". I wonder why that is?

          Those of us who, other things being equal, prefer open-source code -- which can be forked [linuxmafia.com] in order to prevent the project from dying when its creator dies or loses interest -- will continue to prefer MaraDNS, BIND9, Posadis, CustomDNS, Yaku-NS, etc.

          P.S.: I'm sure you'll be equally offended by http://linuxmafia.com/~rick/linux-info/mtas [linuxmafia.com]. Enjoy!

          Rick Moen
          rick@linuxmafia.com

          • Re:Escape (Score:3, Informative)

            by blakestah (91866)
            John Cowan's analysis on license-discuss@opensource.org of the USA Copyright Act's legislative history suggests that modification is not among the rights automatically conveyed.

            It is just not even close to true. Changes FOR YOUR OWN PERSONAL USE do not come close to the issues related to copyright violation (effects on the author's market for the copyrighted material, or his reputation, etc). This is NEVER a default copyright violation. To claim so reaches the heights of absurdity. Talk to a copyright lawyer sometime instead of someone with his head shoved up his ass.

            Those of us who, other things being equal, prefer open-source code -- which can be forked...

            I DO prefer code open source code that can also be forked. But I do not think that is necessary for something to be FREE (as in GNU free), although the OSI would include it in their definition of "open source". There are a LOT of relevant freedoms. DJB includes all but redistributing derivatives. That is a LOT, and by no means reason to condemn his work to hell for eternity.

            P.S.: I'm sure you'll be equally offended by http://linuxmafia.com/~rick/linux-info/mtas

            Not really. I am not so into performance reviews unless performance is an issue for me. My servers are not pegged to the line EVER, performance is a non-issue for ME. What I care about is security and ease-of-use (mainly because they relate to the amount of admin time I need to spend to achieve proper use for my users). And DJB software allows ME, with my very specific small server needs, the absolute minimum admin time to perform as well as I need. And that is all.

            Ask most admins, and they will tell you a similar story. The best no-cost software is the one you have to spend the least time dorking with. If it is OSI open source as well, so much the better. If not, well, I'll wait until something better comes along that is OSI open source. But only if DJB's software fails or needs upgrading sometime in the next 20 years. Which is unlikely.
            • Afterthought: The right to fork is such a fundamental assumption of the open-source model that it's easy to forget other vital reasons for it, beyond just the code being maintainable after its owner decides to quit. I posted before thinking of those.

              When we say something is "open source", we're also implying the right to create derivative works descended from that codebase. E.g., the most important long-term fact about the Berkeley NET2, 4.4BSD, 4.4BSD-Lite, and 4.4BSD-Lite2 releases is that we got 386BSD, and then {Free|Net|Open}BSD from them. Had the U.C. Berkeley Computer Science Research Group used a Bernstein-style no-forking-allowed licence, there would have been none of those things: Their creation would have been illegal.

              So, I think if you mull over your assertion that you "don't think that [a right to fork] is necessary for something to be free (as in GNU free)", you'll see that this right actually is absolutely vital and essential to the very concept.

              Rick Moen
              rick@linuxmafia.com

    • Re:Escape (Score:3, Informative)

      by AirLace (86148)
      djbdns is a great codebase, but it's starting to suffer from a few issues. Find a vulnerability and you're not even allowed to release a fixed version! The license is in some ways _more restrictive_ than (dare I say it) Microsoft's Shared Source.

      There hasn't been a djbdns release since 12-Feb-2001 [freshmeat.net] and the project is bound to go stale sooner or later if djb does not renew his interest. How many companies or networking professionals out there are going to use DNS software which has a single human point of failure? I won't even go into the "hit by a bus" argument.

      Granted, djbdns comes with some cute gimmicks like the "security guarantee [cr.yp.to]". But for all of BIND's problems, the fact that it's open source makes it the better option in this case. Better the devil you know..
      • Re:Escape (Score:4, Insightful)

        by bozoman42 (564217) on Tuesday November 12, 2002 @03:59PM (#4653392) Homepage
        Find a vulnerability and you're not even allowed to release a fixed version!

        That's assuming you ever find one. qmail's withstood the security guarantee since 1998. djb tends to write fairly good software... Besides, people are allowed to release unofficial patches to djb projects and quite a community has grown up around additional features. See qmail.org [qmail.org] and tinydns.org [tinydns.org].

        There hasn't been a djbdns release since 12-Feb-2001 [freshmeat.net] and the project is bound to go stale sooner or later if djb does not renew his interest.

        Oh come on. If something works well and implements the standards, why should you bother to add more gimmicks? "If it ain't broke, don't fix it."

      • Re:Escape (Score:2, Informative)

        by Anonymous Coward
        > There hasn't been a djbdns release since 12-Feb-2001 [freshmeat.net] and the project is bound to go stale sooner or later if djb does not renew his interest.

        Code doesn't "go stale." djbdns works, and it's not going to rot and stop working if Dan doesn't change it.

        As for his losing interest, he's recently revamped all of the djbdns documentation and has been active on the djbdns mailing list.
      • Re:Escape (Score:2, Insightful)

        by innerFire (1016)

        There hasn't been a djbdns release since 12-Feb-2001 and the project is bound to go stale sooner or later if djb does not renew his interest.

        Maybe it hasn't been updated since Feb 2001 since it's complete and doesn't need any new updates? Is that such an amazing concept?

      • If you find a bug, you can announce it and publish a patch. I have never seen anyone publish a fixed version instead of a patch before, why do you insinuate that would be somehow a good idea?

        Besides, the project has not been updated because there is no need. djbdns just works. If you need more functionality than the stock package provides, there are several patches. I know because I wrote (and publish) one [www.fefe.de].

        The rest of your "arguments" I will not go into because they rely on flawed assumptions.

      • Wow, you're dumb. (Score:4, Interesting)

        by tqbf (59350) on Tuesday November 12, 2002 @06:30PM (#4654653) Homepage

        You say the djbdns "license" is "more restrictive" than Microsoft's "shared source license".

        You don't know what you're talking about. Dan Bernstein does not allow you to redistribute FORKS of djbdns. You are very explicitly allowed, in perpetuity, regardless of what Dan says next year, to redistribute djbdns source tarballs with a specific MD5 checksum. Obviously, you are also allowed to publish patches and detailed vulnerability reports. You're simply not allowed to distribute adulterated source code or your own "fixed" binaries.

        This is of course a moot point. There has never been a published vulnerability in the qmail or djbdns codebase. qmail is one of the most widely used MTAs on the Internet [cr.yp.to]. The incentive to find vulnerabilities is huge. Bernstein's methodology is correct and his understanding of the Unix secure coding problem is complete.

        You say that there hasn't been a djbdns release since last year and offer that as evidence that djbdns is going "stale".

        You don't know what you're talking about. There hasn't been a new qmail release in years. qmail remains one of the most popular MTAs on the Internet, contending seriously only with the diminishing Sendmail hegemony and Microsoft's products. There are no new qmail releases because qmail is complete, hasn't had any security problems, and does virtually everything anyone wants an MTA to do. There hasn't been a new djbdns release because djbdns is complete, hasn't had any security problems, and does virtually everything anyone wants a DNS server to do.

  • And I guess... (Score:5, Insightful)

    by nagora (177841) on Tuesday November 12, 2002 @03:13PM (#4652932)
    ...that's why I run Bind 9 and keep it updated.

    TWW

    • Re:And I guess... (Score:3, Informative)

      by dsb3 (129585)
      > ...that's why I run Bind 9 and keep it updated.

      The more pressing concern is that parts of bind4 and bind8 are so far ingrained in standard system libraries and other binaries that simply changing to use bind9 as your nameserver doesn't remove the old, buggy code from your system.

      • Re:And I guess... (Score:3, Informative)

        by RollingThunder (88952)
        Not really a good argument though (if I understand you right). If it's the system libraries and precompiled binaries you're worried about having BIND4/8 "cancer", then it doesn't matter *what* you do - BIND9, TinyDNS, MaraDNS, DJBDNS. That cruft will still be in there, until you recompile everything without said base libs.
      • Re:And I guess... (Score:5, Informative)

        by Zapman (2662) on Tuesday November 12, 2002 @03:34PM (#4653157)
        This is not very valid, since this is an exploit to attack DNS *SERVERS*. Not clients with the shared libs. Besides to attack a client, they first need to get you to go to some compromised DNS server, with an application utilizing the bad resolver libs.

        Besides, there are some good security points you should be doing anyway on the server. Unless you must have it, turn off recursion:

        acl safenets { 127.0.0.1/32; your.internal.ips/??;}

        options {
        allow-transfer { safenets; };
        allow-recursion { safenets; };
        }

        between that, a solid chroot, and a solid setuid, you'll have beaten 99% of the bind problems you'll have.
        • Re:And I guess... (Score:5, Informative)

          by Phs2501 (559902) on Tuesday November 12, 2002 @04:17PM (#4653518)
          Also, if you're serving DNS, get a good secondary DNS provider. Put them in as both your primary and secondary NS records. Then firewall port 53 and only let their hosts connect.

          You still get the same effective service without nearly as much risk of random idiots exploiting buffer overflows.

  • by MORTAR_COMBAT! (589963) on Tuesday November 12, 2002 @03:13PM (#4652935)
    Does TinyDNS support internal and external views? By this I mean, can it return a different IP for the host "foo.my.com" based on what subnet a client is connecting from (e.g., return 192.168.10.11 for all clients in 192.168.* and return 4.3.17.45 for all clients outside of that)? If so, I will switch. If not, I need that function of Bind 9.
    • by dsb3 (129585) on Tuesday November 12, 2002 @03:16PM (#4652972) Homepage Journal
      > Does TinyDNS support internal and external views?

      Yes. This page shows you how http://cr.yp.to/djbdns/tinydns-data.html [cr.yp.to]
  • by mickwd (196449) on Tuesday November 12, 2002 @03:17PM (#4652989)
    Alternatively, you could update to the latest version of BIND.

    From the advisory:

    "BIND 9 was not affected by any of the vulnerabilities described in this advisory."
  • by Anonymous Coward on Tuesday November 12, 2002 @03:17PM (#4652990)
    linx pro [cjb.net] has more information on the exploit, including patches to fix it.

    Does MS fix their vulnerabilities that fast? Judging by the number of klez variants in my inbox, I'd say "no".
    • Link is a 404. Anyone?

    • Klez was fixed before it was released. Just because the users don't patch doesn't mean that MS didn't supply one.
    • Does MS fix their vulnerabilities that fast?

      Considering that according to the BIND history page [isc.org] BIND4 has been out since the 80s and BIND8 since 1997, I'd say this isn't exactly a glowing example of OSS's "quick fixes".
      • OSS' quick fix to BIND 4 and BIND 8 was to release newer versions. BIND 4 is a hopeless clump. BIND 8 was a partial rewrite. BIND 9 was a complete rewrite precisely because BIND 8 wasn't a good basis for a new start.

        The problem, if you want to call it that, with OSS is that once you release something broken, you have to hear bug reports about it for the rest of your life. I still occasionally hear from people who are running pre-1.0 snapshots of the ISC DHCP server. That's just how it is in the open source world.

        In 2150, some idiot on the Mars colony is going to get hacked by a guy in Plano, TX, because he or she is still running BIND 4 on the Marinaris City web server.
    • Does MS fix their vulnerabilities that fast?

      Yes. And if the patch is slow in coming out, it's because they are regression testing it. Do open source clients regression test their patches against thousands of machines with different configurations, or just release it as-is and post followup patches if they have problems?

      Judging by the number of klez variants in my inbox, I'd say "no".

      The only thing that proves is that the majority of users don't keep their systems patched, since Microsoft has made Outlook immune to viruses (yes, IMMUNE COMPLETELY IMMUNE)... been that way for over a year now, maybe approaching 2 years.
      • by evilviper (135110) on Tuesday November 12, 2002 @11:45PM (#4656587) Journal
        Microsoft has made Outlook immune to viruses

        It wasn't long ago that a forged 'trusted' mime type would allow an .exe to be automatically executed without warning. So please explain this "immue to viruses" thing, it doesn't make any sense to me.
      • The only thing that proves is that the majority of users don't keep their systems patched, since Microsoft has made Outlook immune to viruses (yes, IMMUNE COMPLETELY IMMUNE)... been that way for over a year now, maybe approaching 2 years.

        Saying such thing is completly unprofessional. It's like selling the unsinkable ship, the unfailable airplane, the unbreakable firewall, etc. etc. Anybody telling nonsense like that should get an unprofessional stamp on his forehead.

        Yes. And if the patch is slow in coming out, it's because they are regression testing it. Do open source clients regression test their patches against thousands of machines with different configurations, or just release it as-is and post followup patches if they have problems?

        Oh and thats why service packs often introduce new bugs. And thats why some fixes are exclusive. Meaning you can apply fix A or fix B. applying both patches will not work. If you apply fix A you get Bug C. Talk with some _real_ admin of a larger microsoft network, you will hear the tears.
  • maradns (Score:3, Informative)

    by zdzichu (100333) <zdzichu@@@irc...pl> on Tuesday November 12, 2002 @03:18PM (#4652998) Homepage Journal
    This is why I run MaraDNS [maradns.org].
  • by SpaFF (18764) on Tuesday November 12, 2002 @03:18PM (#4653000) Homepage
    http://www.isc.org/products/BIND does NOT have the updated versions (4.9.11, 8.2.7, 8.3.4) that addresses these security issues posted yet (as of 1:16 CST). Perhaps slashdot should update the story once the tarballs become available.
  • by pheph (234655) on Tuesday November 12, 2002 @03:19PM (#4653005) Homepage
    Another vulnerability has been found in Microsoft Windows 98...

    Come on, Bind 9 has been out for some time, so don't flip out! [realultimatepower.net]

    • Another vulnerability has been found in Microsoft Windows 98...

      I take that comment to imply: "Windows 98 Second Edition is too old to be supported; all users of Windows 98 Second Edition should upgrade to Windows XP Home Edition." The problem with upgrading from one major version of a product to the next just to fix a bug is that newer major versions will often drop useful features that an older version had. For instance, Windows XP Home Edition loses Windows 98's competent support for running proprietary applications designed for MS-DOS. In addition, XP Home loses the ability to run acceptably on a 133 MHz machine with 32 MB of RAM.

      Does BIND 9 drop major features or require more hardware for a given level of service vs. BIND 8?

      • I think you are absolutely right... However, Windows 98 still has many many more vulnerabilities than Windows XP. You just need to balance security (read: newer) with useful (read: needed) features.
      • Upgrading to BIND 9 (Score:5, Interesting)

        by mellon (7048) on Tuesday November 12, 2002 @03:58PM (#4653384) Homepage
        BIND 9 is slower than BIND 8, because it does a more correct job, but it's not significantly slower for most applications. If you are running a root name server, you will have to buy bigger iron. If you are running a corporate nameserver, you probably won't. For home use, BIND 9 will perform nicely on a 486 (I run it on a Soekris board, for example).

        BIND 9 is also not bug-for-bug compatible with BIND 8, so there are some things you can do in BIND 8 that are broken, that you can't do in BIND 9. So upgrading can require some rework if you happen to have unwittingly tripped over those bugs.

        On the other hand, BIND 9 is a complete, ground-up rewrite of BIND. It works better, is easier to use, and because of the strict practices that were followed in implementation, is much more reliable.

        BIND 9 also supports DNSSEC, which isn't yet widely deployed, but is worth checking out.

        (I used to work for the ISC, so you might think I'm biased, but I wasn't involved with the ISC BIND project, so it's more that I got to look on while they did it, and was there to see some of the design work they did to make it more reliable, I know the engineers who did it, and I really think they did a great job.)
  • by spacey (741) <spacey-slashdot DOT org AT ssr DOT com> on Tuesday November 12, 2002 @03:19PM (#4653012) Homepage
    It was pointed out on the nylug-talk list that the advisory doesn't seem to include any info about whether nominum, paul vixie, or the ISC was notified about the bug.

    Does anyone know if ISS did the right thing, or are they being big doo-doo-heads?

    -Peter
    • by Black Art (3335) on Tuesday November 12, 2002 @03:29PM (#4653120)
      ISS did not inform any of the Unix vendors.

      They are pretty pissed about it.

      Alan Cox's response was "Well we can all express our deep regret at the inability of the ironically named ISC to work with the internet and society in all the announces."

      BTW, Bind 9 does not fix all of these probems and the fixed versions will be out next week.

      This is not the first time that ISS has released information like this without informing the vendors ahead of time.
    • by tekBuddha (546826) <(jem) (at) (unixmercenary.com)> on Tuesday November 12, 2002 @03:32PM (#4653140) Homepage
      It was mentioned on the FreeBSD-Security list this morning that ISS had informed vendors that they were going to go public with this advisory tomorrow and not today. So in answer to your question, Yes, the vendors have apparently been notified.

      This however appears to be yet another situation where ISS has gone ahead and released an advisory before the vendors have actually had a chance to make patches available to the public.

      This is supposed to be a security firm that is trying to assist the public in keeping their boxen secure? If so, I'm really scared of the firms that are out there really trying to do damage.
  • Tips (Score:5, Informative)

    by ekrout (139379) on Tuesday November 12, 2002 @03:22PM (#4653039) Journal
    [] Most smaller networks don't need a large (and dare I say buggy) installation of BIND.
    [] May I suggest djbdns [freshmeat.net] rather than BIND? Its creator says "every step of the design and implementation has been carefully evaluated from a security perspective. The djbdns package has been structured to minimize the complexity of security-critical code. dnscache is immune to cache poisoning. It is advisable to use the package as a secure alternative to BIND."
    [] May I suggest Dnsmasq [freshmeat.net], which is described by its creators as a "lightweight, easy to configure DNS forwarder designed to provide DNS (domain name) services to a small network where using BIND would be overkill".
  • by Anonymous Coward on Tuesday November 12, 2002 @03:24PM (#4653068)
    It's not surprising that bind 4 and 8 have the same vulnerabilities - they're based on the same code base, after all. Bind 9 was 100% rewritten, is modular, and actually *checks its inputs*, avoiding buffer overruns and such.

    It uses RFC-specified zone file format, it's extremely functional (internal/external views of DNS based on query source, TSIG authenticated DNS transactions, DNSSEC authenticated DNS records).

    In the couple of years the bind 9 code has been out there, the only vulnerabilities it's had caused the server to shut itself down immediately, as it realised something was wrong with its input. That's likely to be it's only failure mode in the future - stick a wrapper around it that restarts it when it dies, and you'll be right as rain.
    • In the couple of years the bind 9 code has been out there, the only vulnerabilities it's had caused the server to shut itself down immediately, as it realised something was wrong with its input. That's likely to be it's only failure mode in the future - stick a wrapper around it that restarts it when it dies, and you'll be right as rain.
      No, you'd create a potentially very effective DoS target. If named were to restart each time it received some malformed packets, a motivated script kiddie could easily max out your load.
    • That's likely to be it's only failure mode in the future - stick a wrapper around it that restarts it when it dies, and you'll be right as rain.

      What, like supervise from daemontools [cr.yp.to]?

      Nah. It'll never work.

    • It uses RFC-specified zone file format

      Is it just me, or does the RFC look like it was documenting BIND's implementation, rather than defining a standard which BIND then implemented?
  • by nweaver (113078) on Tuesday November 12, 2002 @03:27PM (#4653086) Homepage
    The potential for a passive worm is actually fairly high, given that the exploit needs to come in response to a DNS query: The worm infects a DNS server, and waits for queries. It responds to those queries from other DNS servers by attempting to infect them.

    The nasty parts: Enough people dual-use their DNS servers (serving as both authoritative master for outside and for their own lookups) that you could get lots of authoritative masters. It also does NOT scan.

    It could be made even stealtier if the exploit, on failure, would still function. On success, it of course functions normally. This might be harder, but, if so, it would be really REALLY hard to detect such a worm.

    It would take a bit of writing to get right, so there is a good window in which to patch your machines. So patch SOON.
    • According to the article, exploiting these bugs will terminate the DNS. There's no mention of being able to infect the server. I'm not sure why the article mentions worms, other than the possibility of h4x0red Win boxes pounding on the bug.
      • by nweaver (113078) on Tuesday November 12, 2002 @03:54PM (#4653343) Homepage
        Two of the attacks are DoS: You crash the server, end of story. One, the buffer overflow, can potentially execute code.

        The only "gotcha" in that exploit is that an attacker needs to control a DNS server which the victim DNS server queries. Thus it is a passive attack, the victim must query you, not the other way around.

        That is why the attacker uses a passive worm: The worm infects a DNS server, which in addition to being the local DNS server, serves as the authoritative master DNS server for some domains. When another DNS server queries the infected authoritative master, the authoritative master's response is designed to compromise the requesting server.

        This compromise is followed by a transfer of the worm code itself, and now the victimized server is now infected as well.

        As I said, this doesn't scan, which makes it particularly nice and stealthy.

        You could also make an active scanning worm as follow: There are 2 kinds of nodes, authoritative DNS servers and other DNS servers. If you infect an authoritative DNS server, the worm knows it. Otherwise, it knows the authoritative DNS server it was infected from.

        The worm "scans" by sending DNS queries (ideally with forged from addresses) which will trigger a lookup from the known corrupted authoritative server. This can then go through the net, rather noisily, and infect all servers which accept remote queries. This process can be sped up considerably by looking through the local cache for a list of all DNS servers that the corrupted machine knows about. Rough guess? Less than an hour to infect everything which can listen to the net, and you still have the passive attack to get DNS machines behind firewalls etc.

        The fortunate thing: Although the possible worms are either very fast (lots of vulnerable machines, topological speedup from using the cache) or very stealthy (no scanning at all, a contageon strategy), both techniques require a fair amount of BIND specific programming to develop and release: You need to not only craft the exploit, but keep bind running and transmit the exploit.

        So no kiddiot can simply drop exploit code into scalper.c and get it to work, instead there is a considerable amount of programming needed. So we do have a significant time window to patch machines, but they do need to be patched because it is a very "worm friendly" exploit pattern.
        • Yeah, I was rereading and realized that I'd skimmed over the SIG Cached RR Overflow Vulnerability. D'Oh!

          As for kiddiots, it only takes one to share his code. (Open Source hax0r tools, must be a good thing right? :^)

  • by rsd (194962) on Tuesday November 12, 2002 @03:34PM (#4653155) Homepage
    Just old versions of bind,
    Bind 4.x and 8.x are vulnerable to this.

    Version 9, which is a complete rewrite from scratch
    and the version that everyone running bind should be using,
    does not suffer this security flaw.

    Slashdot editors should take an extra care when posting
    news like this to avoid FUD and unnecessary panic.
  • by RazzleDazzle (442937) on Tuesday November 12, 2002 @03:36PM (#4653168) Journal
    Answer: OpenBSD [openbsd.org] See subsection 6.8.3.1
    and read this [sigmasoft.com] for why
    • by Krieger (7750) on Tuesday November 12, 2002 @04:00PM (#4653401) Homepage
      Ah, but you didn't tell them why. Though you did provide a link.

      OpenBSD severely audited their BIND 4 code-base and it is very secure. This can be ascertained by looking at their errata pages [openbsd.org] and looking for patches to BIND. There aren't very many at all in the more recent versions.

      Sure it's BIND 4, but it's solid and stable, like DNS is supposed to be.

    • by grub (11606) <slashdot@grub.net> on Tuesday November 12, 2002 @04:22PM (#4653563) Homepage Journal
      This just hit one of the OpenBSD mail lists from Todd Miller re: the bind exploit:

      Based on the ISS and CERT info it looks like OpenBSD's named is vulnerable. However, since named is run chrooted on OpenBSD this shouldn't be such a big deal. When bind 4.9.11 comes out we will spin a patch.

      Note that we do not appear to have the resolver buffer overflow described in http://www.isc.org/products/BIND/bind-security.htm l
      (looks like we fixed it in 1997).
  • by why-is-it (318134) on Tuesday November 12, 2002 @03:38PM (#4653196) Homepage Journal
    For me, it is not really an option to use a tinydns or any other DNS solution other than BIND. Upgrading to BIND9 is not really an option for me either. I work for a large multinational, and we have a lot of UNIX servers (Sun, IBM, and HP in terms of numbers). I get hardware and software support direct from the manufacturer, and if I install an application, or a version of an application that my vendor does not support, I am on my own. These 24-7 support contracts are important to us in being able to sell our services and maintaining our SLA's and availability targets. Those issues aside, I do not want to have to explain to the PHBs that we cannot get support on a particular problem because the application in question is not supported by Sun, or that IBM only supports version 3.4 and we run version 4.0.

    So, it is all well and good if someone out there has the choice to install some other software, but keep in mind that it is not necessarily an option for everyone...
    • What the fuck are you playing your vendor for if they won't provide fixes for known, proven, and public vulnerabilites? If thats your quality of service, are you really losing anything by giving up thier support and installing your own apps?
    • Why not work the contract so that they WILL support the version that is arguably many times more secure and which should be less hassle for them to support (as in they don't have to release a patch everytime ANOTHER bug is found in BIND 8). Whenever we make a contract we make sure OUR needs are met. For instance we have a line item in our contract with MS for Exchange that says the will fix OWA to work with our linux clients, since they don't want to do that they are paying for Ximian network connector liscenses for every linux install we have =) If we can make MS do something like support linux you should be able to get your vendor to support a newer version of BIND that is more secure =)
  • Bind 9.2.1 (Score:2, Insightful)

    by decarelbitter (559973)
    Bind 9.2.1 has been out for a while. If you haven't upgraded yet consider letting someone who does know run your nameservers...
  • BIND (Score:4, Funny)

    by Make (95577) <maxNO@SPAMduempel.org> on Tuesday November 12, 2002 @03:54PM (#4653345) Homepage
    BIND - serving remote shells since 1986 ;)
  • by mcrbids (148650) on Tuesday November 12, 2002 @03:54PM (#4653351) Journal
    Knowing that this might be a vulnerability issue, I immediately logged into my main servers and typed, in each, "up2date -du --tmpdir=/home/tmpdir".

    Before I even realized that this doesn't apply to me, (I'm using Bind 9) all the updates had been downloaded and applied.

    And, I guess, in a week or so, I'll get an email from Red Hat letting me know that I should be running up2date again...

    -Ben
    • == why I love the cron-apt deb

      every night at 4am, my debs are updated. and yes I did remove the -d (download only, no install) flag, so it does real updates nightly.
    • Official Red Hat Statement [redhat.com]

      "Versions of Red Hat Linux since 7.1, and Red Hat Linux Advanced Server
      shipped with BIND 9 are are therefore not vulnerable to these issues.

      Older releases (6.2, 7.0) of Red Hat Linux shipped with versions of BIND
      which are vulnerable to these issues, however a Red Hat security errata in
      July 2002 upgraded all our supported distributions to BIND 9.2.1 which is
      not vulnerable to these issues."
  • Bind9 (Score:3, Interesting)

    by retro128 (318602) on Tuesday November 12, 2002 @03:57PM (#4653374)
    Used to run Bind9, but BIND seems to be suffering from the Microsoft bloat phenomenon. How many megs do you need for serving up DNS?? The BIND 9 decompressed tar file comes out to 2100+ files at 21MB. If I recall the installation process, it took forever to compile and then loaded the system with a bunch of superfluous directories and files. For more complicated installations with more exotic requirements than I have, maybe I can see using BIND9, but for my wimpy little web server that has maybe two or three A records to its name, there's no point, so I use djbdns.
  • I'm scared (Score:5, Funny)

    by mao che minh (611166) on Tuesday November 12, 2002 @03:59PM (#4653393) Journal
    With all of the security news lately, I am too scared to run Apache, IIS, Exchange, lpr, lprng, mySQL, PostgreSQL, Outlook, Outlook Express, map Netware drives to Win 9x clients, X11, use any program that requires glibc, or use BIND 4 or 8 or any DNS for that matter. My computer sits in a locked closet, lacks input devices, and runs only the OpenBSD kernel and nothing else.
  • I like MyDNS (Score:2, Informative)

    by bleachboy (156070)
    I like MyDNS - http://mydns.bboy.net/ - serves records directly from a MySQL database, and easy to set up and manage.

    0.9.5 (development copy at http://mydns.bboy.net/beta/) also supports PostgreSQL.

    Of course, I am biased. ;)
    • This sounds like an interesting product, but I have an even more light weight solution for this ... especially if you run other things on the MySQL DB that MyDNS is running on (like a web site ...)

      Store all of your DNS information in a MySQL db, use the db to make updates, then have a silly shell/C/C++/Java/Perl/PHP script generate the DNS files for you ... this way, there is less over head on the system over all ...

      Please poke holes in my solution ... I'd like to be convinced that this is the best way to manage a large number of DNS entries ...

      Cheers!

    • Re:I like MyDNS (Score:3, Insightful)

      by Animats (122034)
      Clearly that's the way to do it. Every other modern server-based app that needs a database has the database in a separate program and address space. BIND and Sendmail are archaic exceptions to this rule, and look where all the security holes show up.
  • Real geeks just use host files. Here you go:

    /etc/hosts:

    66.35.250.150 slashdot

  • Shameless plug time (Score:5, Informative)

    by Kiwi (5214) on Tuesday November 12, 2002 @04:45PM (#4653773) Homepage Journal
    I am the implementer of a DNS server called MaraDNS. This server was written in response to the demand for a fully funcitonal DNS server which has a open source compatible license (which tinydns doesn't). The webpage for MaraDNS is here [maradns.org]. The 1.0.x branch has stabilized; I am currently working on the 1.2 branch of MaraDNS.

    Another option, if one does not need recursive caching is posadis [sourceforge.net]. There is also pdnsd [t-online.de], which only provides recursive DNS service.

    Security history of various DNS servers:

    • Bind 4 and 8: multiple remote root shells
    • Bind 9: Denial of service vulnerbilities found
    • MaraDNS: Denial of service vulnerabilities found
    • Posadis: remote shell
    • pdnsd: remote shell
  • by KFury (19522) on Tuesday November 12, 2002 @10:56PM (#4656373) Homepage
    "The world's most popular DNS package is once again vulnerable."

    This is the scariest part of the security mentality. Whenever a flaw is discovered everyone freaks and says 'oh, now I'm vulnerable!' until a patch is distributed and 'Phew! Now I'm safe again."

    This is not the right way to look at it. The flaw was there for years, and you were vulnerable to everyone who found it before a whitehat did. What's more, you're *still* vulnerable to every flaw that hasn't yet made it to slashdot's pages, but will in coming months and years.

    Choosing a platform that reacts quickly to patch discovered flaws means only that you're safer from attacks from those people who read the same sources you do, and quickly move to exploit the published vulnerabilities before you can patch them.

    The fact is that it's rarely known how many people discovered a vulnerability before it was made public, and so if you rely on a system that requires frequent hotfixes, however quickly the vendor may react, you are still succeptable to the countless holes that have already been discovered, but not by the good guys.

    The morals of this argument are that it's better to use a system that doesn't have as many holes, to one that patches them 'instantly,' and that unless another vulnerability is never discovered in your platform, you're vulnerable to attack today, and always have been.

Someone is unenthusiastic about your work.

Working...