Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

Bind 4 and 8 Vulnerabilities

Comments Filter:
  • by MORTAR_COMBAT! (589963) on Tuesday November 12, 2002 @02: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.
  • AMEN! (Score:1, Interesting)

    by Anonymous Coward on Tuesday November 12, 2002 @02:14PM (#4652951)
    All hail djbdns! ... now if we could only convinve djb to loosen some licensing issues.
  • by spacey (741) <.moc.rss. .ta. .gro.todhsals-yecaps.> on Tuesday November 12, 2002 @02: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
  • Re:BIND9 (Score:5, Interesting)

    by SpaFF (18764) on Tuesday November 12, 2002 @02:35PM (#4653163) Homepage
    It's funny that they recommend this, yet F.root-servers.net (which is run by the ISC) runs bind 8.3.3.

    F is a virtual server made up of multiple systems and runs ISC BIND 8.3.3 as its DNS server. [isc.org]

  • No, it's secure because no one has ever found a flaw in tinydns. He has a *cash* reward for anyone who can prove that it is flawed. No one has taken then money, in several years of it being offered.
  • Re:Escape (Score:1, Interesting)

    by Anonymous Coward on Tuesday November 12, 2002 @02:38PM (#4653195)
    He's a Stallman wannabe. In other words, an asshole.

    If he's running BIND9 intead of Berstein's program, he's a moron too.
  • Re:AMEN! (Score:3, Interesting)

    by thogard (43403) on Tuesday November 12, 2002 @02:38PM (#4653199) Homepage
    Thats just like the postfix situation. No one has reported bugs.... however if you look at most of the sendmail "bugs" over the last 5 years, you will find they workaround bugs in standard libraries and operating systems, not the main program code. If you look at the patches to sendmail and see if they have are need and applied to other packages, you will find they were needed but aren't applied. None of the people paying for bug reports will pay for bugs in the OS.
  • by Black Art (3335) on Tuesday November 12, 2002 @02:54PM (#4653340)
    The message to the vendors came out at about 11pm.

    The announcement to the public happened about nine hours later.

    The vendors were blindsided by this.
  • Bind9 (Score:3, Interesting)

    by retro128 (318602) on Tuesday November 12, 2002 @02: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.
  • Upgrading to BIND 9 (Score:5, Interesting)

    by mellon (7048) on Tuesday November 12, 2002 @02: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 Krieger (7750) on Tuesday November 12, 2002 @03: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.

  • Re:Pah (Score:3, Interesting)

    by squiggleslash (241428) on Tuesday November 12, 2002 @03:25PM (#4653578) Homepage Journal
    According to Todd Miller, yes, but... [theaimsgroup.com]. Under OpenBSD BIND is chrooted to /var/named, which means its potential for damage if infected is highly limited.

    Those who are stuck with BIND 4 for legacy reasons or whatnot are probably best off switching over to a chroot'd configuration - it's all very easy and the functionality is already built in.

  • Re:AMEN! (Score:5, Interesting)

    by jonadab (583620) on Tuesday November 12, 2002 @04:03PM (#4653929) Homepage Journal
    Sendmail likes to _blame_ things on the OS that are really (at least
    partly) sendmail's fault. For example, being insecure if /usr is
    group-readable. That's just silly; there's nothing inherently
    insecure about having /usr be group-readable. (If it were world
    writable, that would be something else.) (It was /usr, wasn't
    it? It's the thing you have to change in the filesystem to get
    sendmail to be secure on OS X.) IMO there's no excuse for sendmail
    to blame that on the OS; in the first place, sendmail should be
    secure regardless of the filesystem permissions, and in the second
    place if it doesn't need to read such places it should run as a user
    with fewer permissions (e.g., with its own group like Apache does).
    qmail, for all the complaints you can make about its license, at
    least takes responsibility for its own vulnerabilities.

    Are weaknesses in the OSes _partially_ responsible for some of those
    vulnerabilities? Well, sure, but the weakness is exploited through
    sendmail and does not have an impact on competing implementations;
    that makes it sendmail's problem in my book, and blaming it on the
    OS is just a way of shirking responsibility. Do you report the
    vulnerability in the OS? Heck, yes, but you also fix your app to
    not be exploitable through it. The sendmail people need to drop the
    "don't blame sendmail" attitude and write secure software. I know
    it's hard being the leading server software in a particular market,
    but when openssl can be exploited because of an issue in certain
    kernels, they patch openssl. When the openssl issue causes some
    Apache installations to be vulnerable, the Apache people release
    an advisory. It shouldn't be about placing blame; it should be
    about _fixing the problem_. The sendmail people are more interested
    in pointing fingers.

    Not that there aren't things you _can't_ work around, that have to
    be fixed at the OS level. Keeping unauthorized local users out of
    the data on a system without filesystem permissions (e.g., Win98),
    for example, is not something that can be fixed by the app, at least
    not easily. But at some point a line is crossed where the problem
    _should_ be fixed in the app. Especially if it's an app that listens
    on ports or otherwise receives data from random entities on the net.
    sendmail has a long history of being vulnerable -- way worse than
    BIND, right up there with IIS and Outlook. And it's going to
    continue to be that way for as long as they keep wanting to blame
    their issues on the OS.
  • Wow, you're dumb. (Score:4, Interesting)

    by tqbf (59350) on Tuesday November 12, 2002 @05: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.

  • Re:QPL? (Score:4, Interesting)

    by rickmoen (1322) <rick@linuxmafia.com> on Tuesday November 12, 2002 @07:01PM (#4655414) Homepage
    "Electrum" wrote:

    Simply calling that a ``DoS attack'' is stretching the truth.

    I'm sorry, but what do you think a DoS attack is? The attack mode described would be a classic example, in fact. Whereas, calling it a "security hole" is actively misleading, by omission.

    Besides, as you are perfectly well aware, I did not "simply" call it a DoS attack: I stated precisely and concisely what occurred.

    The point was to call attention to yet another example of the polemics characteristic of the DJBware camp, and their tendency to shade the truth. In light of which, you have quite a bit of nerve selectively ignoring parts of my accurate characterisation in order to label it "stretching the truth". I'm not surprised, but I am disappointed.

    Rick Moen
    rick@linuxmafia.com

  • by bourne (539955) on Tuesday November 12, 2002 @07:20PM (#4655546)

    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.

  • by KFury (19522) on Tuesday November 12, 2002 @09: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.

You had mail, but the super-user read it, and deleted it!

Working...