Forgot your password?
typodupeerror
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.
  • 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".
  • maradns (Score:3, Informative)

    by zdzichu (100333) <zdzichu AT irc DOT pl> on Tuesday November 12, 2002 @03:18PM (#4652998) Homepage Journal
    This is why I run MaraDNS [maradns.org].
  • Re:And I guess... (Score:3, Informative)

    by dsb3 (129585) on Tuesday November 12, 2002 @03:18PM (#4652999) Homepage Journal
    > ...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.

  • 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.
  • 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".
  • Re:And I guess... (Score:3, Informative)

    by RollingThunder (88952) on Tuesday November 12, 2002 @03:24PM (#4653066)
    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.
  • 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.
  • 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 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.
  • 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.
  • 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
  • Re:Escape (Score:3, Informative)

    by AirLace (86148) on Tuesday November 12, 2002 @03:36PM (#4653175)
    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..
  • by spacey (741) <[spacey-slashdot.org] [at] [ssr.com]> on Tuesday November 12, 2002 @03:47PM (#4653283) Homepage
    The format is pretty flexible. From the above page, the important part is:

    For versions 1.04 and above: You may include a client location on each line. The line is ignored for clients outside that location. Client locations are specified by
    % lines:
    %
    lo:ipprefix
    means that IP addresses starting with ipprefix are in location lo . lo is a sequence of one or two ASCII letters. A client is in only one location; longer prefixes override shorter prefixes. For example,
    %in:192.168

    %ex
    +jupiter.heaven.af.mil:192.168.1.2:::in
    +jupiter.heaven.af.mil:1.2.3.4:::ex
    specifies that jupiter.heaven.af.mil has address 192.168.1.2 for clients in the 192.168.* network and address 1.2.3.4 for everyone else.

    This shows, using the shorthand "in" for internal and "ex" for external, the syntax for creating the equivelant of bind's views. Its pretty flexible. And not hard at all.

    I do wish that djb could have made his format a bit more consistant, but when I think about it its probably impossible considering that DNS requires some oddbal fields. Having written a parser, its pretty darn easy to read and parse, especially compared to trying to compare it to the bind format after an axfr, where it keeps redifining "@".

    -Peter

  • 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.
  • 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
  • I like MyDNS (Score:2, Informative)

    by bleachboy (156070) on Tuesday November 12, 2002 @04:06PM (#4653448)
    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. ;)
  • Re:Escape (Score:2, Informative)

    by Anonymous Coward on Tuesday November 12, 2002 @04:10PM (#4653472)
    > 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: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 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 Fefe (6964) on Tuesday November 12, 2002 @04:28PM (#4653607) Homepage
    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.

  • Re:Escape (Score:3, Informative)

    by Anonymous Coward on Tuesday November 12, 2002 @04:32PM (#4653640)
    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 ?
  • by martial (107984) on Tuesday November 12, 2002 @04:33PM (#4653651)
    I was running tinydns on my home computers and the servers I maintain at work, but I was getting frustrated with the locations of the files and the use of non standards services. Note that this is my opinion and I understand that other people may want to continue using it.

    But in case your installed it on your system in the "standard" location (/usr/local) (Note: I used dnscache and dnsclog as the users to create), here is a little script to "wipe" it (remember to have bind ready to take over after you kill the sv processes remaining).

    rm -rf /package
    rm -rf /command
    rm -rf /service
    rm -rf /etc/dnscachex
    rm -rf /var/spool/djbdns
    rm -f /var/spool/mail/dnsc*
    rm -f /etc/dnsroots.global

    perl -pi.old -e 's%^(SV:123456:respawn:/command/svscanboot)%#$1%' /etc/inittab

    userdel dnscache
    userdel dnsclog

    cd /usr/local/bin
    foreach i (fghack pgrphack readproctitle supervise svc svok svs* envdir envuidgi
    d multilog setlock setuidgid softlimit tai64n* axfr* dns* pickdns* random-ip rbl
    dns* tinydns* walldns*)
    rm -f $i
    end

    Hope this helps,

    -- M
  • 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 tswinzig (210999) on Tuesday November 12, 2002 @04:54PM (#4653850) Journal
    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 Anonymous Coward on Tuesday November 12, 2002 @05:08PM (#4653968)
    ISS and ISC worked together on this. ISS found the
    vulns, ISC worked with the vendors, and both of us
    worked with CERT and coordinated the announcements.

    Paul Vixie
    Chairman, ISC
  • by markcox (236503) on Tuesday November 12, 2002 @05:13PM (#4654010) Homepage
    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."
  • 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

  • by Fry a Lad Up (513448) on Tuesday November 12, 2002 @05:55PM (#4654396)
    Sendmail likes to _blame_ things on the OS...

    Actually, it's more the other way 'round. People like to blame things on Sendmail. Usually people who haven't looked at it years, if it all. Would you blame the 2.[45] Linux kernels for 1.0's lack of support for fireware or USB.

    Neither Sendmail.org nor Sendmail, Inc has a long history of being vulnerable. Commercial OSes have a history of running old Sendmail5.65 distros. Sendmail.org, on the other hand, has a history of being blamed for vulnerabilities it neither caused nor can be responsible for fixing.

    It has a history of Slashdolts making ignorant critiques like yours: Sendmail doesn't complain problem about group-readable /usr; it complains about group-WRITABLE /usr. It does complain about group-readable authentication databases.

    Show us an option that Sendmail should code around. One that actually exists, I mean! You'll find that (a) satisfying Sendmail without DontBlameSendmail will be more secure and (b) the circumstances are the choice of the OS distro or the installation's Sys Admin (and likely an oversight).

  • Re:QPL? (Score:3, Informative)

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

    He doesn't need to. djbdns doesn't have a license and doesn't need one: http://cr.yp.to/softwarelaw.html [cr.yp.to]

    It would be more accurate to say that djbdns has the default licence that implicitly attaches to creative works by default application of copyright law -- in the absence of an explicit licence grant. The terms of that default licence, described by Prof. Bernstein mostly accurately (other than, according to John Cowan, those concerning modifications [linuxmafia.com]) at the URL you posted, are those of proprietary software, rather than open source. (Thus, any software instance issued without an explicit licence is proprietary by default.)

    BIND 9 has had security holes.

    Tell the whole truth, please: A BIND9 version was subject to one type of DoS attack. Sending a specific DNS packet to the daemon triggered that instance going into some sort of test mode where it performed an internal consistency check, effectively shutting it down.

    Rick Moen
    rick@linuxmafia.com

  • by BitHive (578094) on Tuesday November 12, 2002 @07:04PM (#4654960) Homepage
    This is not a troll, but you left out one:
    • djbdns: no reported vulnerabilities
    Hurrah to people who know how to write software properly.
  • Re:QPL? (Score:4, Informative)

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

    First there was sendmail. Then qmail. Then, a long time later, other options.

    Noted. But I'm talking about how DJB groupies tend to behave today. See for yourself: Look on the various Qmail pages. Read the Qmail HOWTO.

    That might have been a reasonable excuse years ago. Today, it looks a whole lot like intellectual dishonesty: Beating up on monolithic Sendmail, especially in the usual fashion that fails to credit it for the major improvement of dropping privilege according to role, is a whole lot more facile rhetoric than comparing it against the similarly-designed Postfix (ne Vmailer) codebase.

    First, there was BIND. Then, djbdns. And now, VERY recently, other replacements.

    Actually, some (such as Dents) have been around for quite a long time. Most people were not aware of them until after I expanded my essay [linuxmafia.com] to include open-source alternatives to all the proprietary DJB packages. Which in turn I was motivated to do out of annoyance at Prof. Bernstein sending me belligerent e-mails essentially making legal threats (talking about my essay being "against the law" and containing "libel"). Funny how these things work out, isn't it?

    I don't think proprietary is appropriate.

    That's too bad, because that's what the word means. One key element whose absence makes us consider a package proprietary is not having the right to fork [linuxmafia.com]. Not having that possibility as a safety valve means that the package is at risk of becoming effectively unmaintainable if its copyright holder stops issuing new versions (and doesn't grant additional rights to fix the problem).

    Prof. Bernstein is certainly under no obligation to grant such rights, and he's quite generous in granting those he does -- but the only fitting term for the result is "proprietary code".

    DJB software provides the user ALL of the GNU freedoms.

    That, sir, is simply wrong. Hmm, I don't usually pay a whole lot of attention to Stallman's "four freedoms" essay, since it's a bit too vague to be useful. I prefer the DFSG and OSD, generally.

    However [rummaging through the FSF propaganda], Prof. Bernstein doesn't choose to meaningfully grant FSF freedom #4. To quote that essay: "The freedom to redistribute copies must include binary or executable forms of the program, as well as source code, for both modified and unmodified versions. (Distributing programs in runnable form is necessary for conveniently installable free operating systems.) It is ok if there is no way to produce a binary or executable form for a certain program (since some languages don't support that feature), but you must have the freedom to redistribute such forms should you find or develop a way to make them."

    His software works dern well, and is free enough for anyone whose concern is getting their work done.

    Until the day Prof. Bernstein hangs up his hat, at which point the projects basically become unmaintainable. (Maintaining a codebase solely through source patches against a legacy final-version source tarball wouldn't really be feasible for long.) And that is of course the prospect that hangs over users of all such software.

    Rick Moen
    rick@linuxmafia.com

  • Re:Escape (Score:5, Informative)

    by D. J. Bernstein (313967) on Tuesday November 12, 2002 @08:02PM (#4655417)
    ``I tried djbdns, and it simply did not have the functionality I needed for my application. (mainly, multiple DNS views)''

    djbdns has supported client differentiation since January 2001, version 1.04.

    For comparison, BIND 9.0.0 was released in September 2000. It was practically unusable. The BIND company now says that BIND 9.0.0 had more than six hundred bugs, many of them quite serious.

    Are you saying that you tried djbdns two years ago, had to use BIND 9's ``views'' instead, managed to survive BIND 9's bugs, and haven't looked at djbdns since? If so, take another look. Client differentiation is substantially easier with djbdns than with BIND 9.

    Or are you saying that you tried djbdns more recently, and somehow acquired the false impression that it doesn't support client differentiation? If so, how did you acquire that impression? Is there something in the documentation that could be improved?

  • Re:Escape (Score:3, Informative)

    by blakestah (91866) <blakestah@gmail.com> on Tuesday November 12, 2002 @08:28PM (#4655591) Homepage
    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.
  • Re:Escape (Score:3, Informative)

    by D. J. Bernstein (313967) on Wednesday November 13, 2002 @02:12AM (#4657268)
    Rick Moen is an idiot. See an attorney's summary of Aymes v. Bonelli [flabar.org], 47 F.3d 23 (2d Cir. 1995), or the case itself, for an example of your right to modify copies of software that you own.

    Moen's source John Cowan is correct about one thing: namely, CONTU said that users ``should'' have modification rights, not that they ``do'' have modification rights. What Cowan and Moen fail to understand is that (1) CONTU was giving recommendations to Congress regarding changes to copyright law and (2) except for something that isn't relevant here, Congress followed those recommendations.

    Cowan says that ``there is no evidence that the right ... was in fact added'' to copyright law. In fact, the evidence is overwhelming. (Cowan logic: if Cowan hasn't seen the evidence, the evidence must not exist.)

    Cowan says that my quote from CONTU is ``misleadingly selective,'' and that my ``claim that private modifications are allowed'' is not ``credible.'' In fact, modifications are allowed. (Cowan logic: if there isn't evidence that he's wrong, then he must be right.)

    Moen says that Cowan ``furnished a more-complete quotation,'' finding that it ``contradicts'' my summary and that my quote was ``distortively selective.'' In fact, my comments are entirely consistent with the CONTU report. (Moen logic: If Cowan puts the most words in quotes, Cowan must be right.)

    Moen says that Cowan ``convincingly disputed'' my summary. And so on ad nauseam. It's rather amazing how tall a tower of stupidity can be built on a foundation of ignorance.

  • by evilviper (135110) on Wednesday November 13, 2002 @04:05AM (#4657596) Journal
    Are you a troll or just ignorant?

    Systrace will likely stop this attack from even being effective.

    Chroot'ing means that you give the program access only to an almost empty folder (basic config files).

    And Droping to a normal user means that it no longer has root permissions (and so can't even overwrite the few files in the chroot).

    Any one of these three security measures should stop this exploit from accomplishing anything. It's practically impossible that all three could be circumvented.

    So, no, my DNS server isn't going to be sending out ANYTHING.

    Besides, I haven't even implimented user/group filtering with PF yet. That would mean, even if an attacker got around systrace, and the chroot, they would not be able to transmit any data except on the ports I've allowed (e.g. only 53), and I could even set up a stateful rule that would only allow port 53 traffic in response to an outside request...

    Computer security has been a complete mess for some time now. It's beginning to look like it may be straightening out (provided you have a good admin that can impliment all of the available security tools).
  • Re:QPL? (Score:3, Informative)

    by rickmoen (1322) <rick@linuxmafia.com> on Wednesday November 13, 2002 @05:26AM (#4657753) Homepage
    Blkdeath wrote:

    How many root nameservers run DJBDNS?

    It's actually pretty appalling that all 13 root nameservers run BIND8 -- that any of them do, actually, but particularly that they all do. Fortunately, it looks as if the RIPE.NET root nameserver will switch to the new, and very promising (for authoritative nameservice only) NSD package, which is BSD-licensed.

    No AXFR w/TSIG support yet, but it's under development.

    Rick Moen
    rick@linuxmafia.com

It is impossible to travel faster than light, and certainly not desirable, as one's hat keeps blowing off. -- Woody Allen

Working...