Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet

Vixie And Others On Members-Only BIND Info 118

Posted by timothy from the putting-a-fork-in-it? dept.
Pac writes: "ISC suggestion of a new 'members-only' security information list for BIND has been the topic of the week over the Internet security community. Kurt Seifried has interviewed Paul Vixie, head of ISC, about the announcement for SecurityPortal. The article includes some (not very suporting) comments from Bugtraq users, including Vincent Danen's (from MandrakeSoft) and Theo de Raadt's (from the OpenBSD project)." If joining the program already in progress, you may want to take this as a chaser to the BIND vulnerabilities and members-only BIND info stories of a few days ago.
This discussion has been archived. No new comments can be posted.

Vixie And Others On Members-Only BIND Info More

Vixie And Others On Members-Only BIND Info

Comments Filter:
  • Regular users should be aware of such issues, as it makes them more informed consumers. I'd switch ISP's really quickly if I found out my ISP wasn't patching their servers with the latest software, as nefarious people (you know who you are) can do all sorts of nasty thing with a cracked primary DNS server, or a open mail relay, etc.

    In a similar vein, bum tires are of iterest primarily to car mechanics and other "car geeks" who will be upgrading the tires, but users of the cars should be aware of the problem as well.

    Granted, they don't have to study the matter in the detail a hacker would a Bugtraq memo on the inner workings of a forged BIND exploit, or the chemistry as to why the tires suck... just enough to know that there is a problem and that they probably should contact their admins to see what is being done.

  • Looks like it's time to replace BIND with djbdns [cr.yp.to]

    Funny you should say that - after reading about the BIND priesthood's latest moves I decided to do exactly that. The man's a pain in the rear sometimes but over the years I've learned that his software works, and works well.

    djbdns takes an entirely different approach to DNS serving, breaking the problem apart into completely separate components which are addressed by completely separate programs. This takes some getting used to, and it's not always immediately apparent how you can address every esoteric situation that you could with BIND's kitchen-sink approach (mainly because the different programs can't, of course, share port 53). Plus, you have to tread down the slippery slope of DJB replacements for a score of core system services - inetd, init, and so on. But so far I've got DNS servers running in 1/5 the memory footprint, serving queries about 10% faster, from a source that history suggests is all-but-guaranteed to be free of security problems.

    Up to now, I hadn't even considered replacing BIND with anything else - just salivating hungrily when new versions came out, in hopes that they might actually run for more than a month or two without an urgent security upgrade. I guess it seemed somehow easier to use the same package everyone else did, if only because experts and books are easy to come by. But now that their long-awaited conclusive answer to the constant plague of security problems is to formally and officially sweep them under the rug, it looked like time to hitch my wagon to a new star. Obviously the underlying problem is not getting solved anytime soon.

  • 'man named':

    -u user_name

    • Specifies the user the server should run as after it initial izes. The value specified may be either a username or a nu meric user id. If the ``-g'' flag is not specified, then the group id used will be the primary group of the user specified (initgroups() is called, so all of the user's groups will be available to the server).

    and:

    [mark@hubcap mark]$ ps aux | grep named
    named 403 0.0 4.5 2776 1268 ? S 10:09 0:00 named -u named

    Bind has been able to run as a non-root user for ages now, certainly over a year.

  • The other alternative is for everybody who isn't in the little clique to report the bugs to bugtraq and not to the ISC closed group, if most of the bugs go to bugtraq then what is the point if this forum?
    ----
  • Every single one of us uses BIND on a daily basis. If I were to pull a statistic out of my ass, I'd say 95% of the name servers on the Internet use BIND, including all of the root servers. Every query you do uses BIND, every web site you view uses BIND. Quite simply, BIND is God. It's fascinating but true.

  • Re:No real explanation of fees (Score:3)

    by JCCyC ( 179760 ) on Saturday February 03, 2001 @11:35AM (#459189) Journal
    Split the code. But he's already made plans for that I bet.

    Is there anything he can do? BIND being BSD-licensed, anyone can just slap a GPL on it, call in OpenBind or GnuBind or GnuDNS and that's about it. At the VERY worst, maybe it'd be required to show a message like "this software contains code (c) blahblah". Correct me if I'm wrong, but I'm pretty sure I'm not.

    (*sigh*) I wish DJB wouldn't be so anal about his licensing (forced install locations? Sheesh!) I administered qmail, and it rocks. I bet djbdns is just as well-done.

  • How about everyone just get over it and learn to deal with direct e-mail marketing like adults? I mean, if you guys had your way you'd shoot the postal carrier when he delivered junk mail to your door. Direct e-mail marketing (or spam as you call it I suppose) is on the rise and it isn't going anywhere. We might as well just learn to accept it. If you're really sick of Direct e-mail marketing you could always setup your mail client to discard all mail except those from people on an approved list. Then, no more "spam". All these silly RBL organizations are doing is spinning their wheels anyway. If there was a way to stop direct marketing then I wouldn't be interrupted during dinner by telemarketers or have to sift through 10 lbs of junk mail to get to the 2 letters I'm interested in. The courts have done nothing but support "spam" so why are we even bitching about it? If you're really against it, talk to your congressmen and get it legislated out of existence along with all other forms of direct mail. If you don't want to, then deal with it.
  • Nope, the analogy is pretty good. It is always much easier to destroy than to create.
    Considering vehicle weight, probably better to overinflate slightly rather than underinflate slightly. If the goons in the tire shop know that, then maybe everybody is a tad safer.

  • Get a clue.

    My postman doesn't make me sit there and open all my mail. I don't get deluged with 20-30 pieces of junk every day on paper. What the postman brings isn't going to expand exponentially because the sender pays to have it sent, whereas spam is paid for by ripping people off. My bandwidth is used up when POP3 downloads the junk before I get to see it. Bogus subjects mean sometimes people click on it to read it anyway so just clicking delete still means time wasted.

    And yes there is a way to stop telemarketing and I've done it already. And there is a way to stop SPAM and congress doesn't even need to get involved. You just hate it because we cut off so many of your relays.

  • It there's going to be a major fork, how about we fix that other humongous problem [internic.net]. OpenBIND would certainly be nice if it included OpenNIC and OpenRootServers. ;-) The DNS system has got to be the funniest example of something sustained only by people's unwillingness and laziness to change to something else because what they have is "good enough". We're paying for domain names from companies because no one really bothers to implement a replacement that has gotten widespread enough support.
  • Stop relying on perfect software to protect your systems. Run the damn thing in a chroot[...]
    Defense-in-depth is a Good Thing, but this doesn't mean you should relax and get sloppy with one layer just because you have other layers behind it.

    Suppose you were choosing which of two cars to buy. One model has a history of catastrophic brake problems, and on two recent occasions has been recalled after negative press following bouts of spectacular fatal collisions. (For the sake of argument, assume the two models are comparable in other respects.)

    Do you (A) buy the model with dodgy brakes, but install a better airbag and seatbelt and write a will; or (B) buy the other one instead, possibly installing the safety equipment anyway?

  • Where does it say that the bind source will become closed and protected

    From the article:
    Features and benefits of "bind-members" status will include:
    1. Private access to the CVS pool where bind4, bind8 and bind9 live

    It's hard to know for sure, but that seems to be exactly what the article's saying.

  • nefarious people (you know who you are) can do all sorts of nasty thing with a cracked primary DNS server, or a open mail relay, etc.

    But to who? Not my box. Just the DNS server (one would assume, if the ISP was running only the DNS on that server).

    I don't think this hack can trace back through my ISP's DNS, find my machine, and hack into it.


  • Why in the heck do sendmail and BIND keep appearing together in these messages? They were not written by the same person.

    maru

  • I wasn't referring to a remote-root exploit. The recently announced BIND exploits that are the whole topic of discussion are not remote root either (at least not on a properly-configured BIND installation).

    maru

  • If ISC doesn't back off, we're soon gonna have OpenBind.

    This is probably the best thing that can happen. Actually, it usually takes one good kick in the teeth for us to realise that what we are using is a lump of crap and we'd better do something about it. I am so fed up of bind. Hopefully, being forced into admitting we have a big problem might give the incentive to fix it. It has been known to happen.

  • True, the odds of them getting to your personally secured OpenBSD box sitting behind a firewall from the ISP's primary DNS are slim.

    However, the amount of damage they could cause on the networking/server side of things is potentially massive, which may hurt you in other ways besides them getting root on your personal machine-- your buisness webpage could be redirected to a porn site, for example.
  • Occasional security problems?! BIND has a history as a heap of junk. There's no reason at all to put up with that.
  • First he steered his MAPS project from something
    great to something totally awful, and how he's
    out to ruin BIND. Oh well. Time for a new
    BIND, free of megalomaniacs.
  • DJB's whole notion of breaking these things up into seperate programs is the unix philosophy. You may argue that the unix philosophy is weird, but "do one thing and do it well" has always been what the UNIX culture stands for, and DJB understands it better than most, I think.
  • I guess so - this position is 180 degrees from where he used to be, back when he was useful to the community writing code...

  • For two reasons. First, they're both good examples of the huge, monolithic, everything-but-the-kitchen-sink approach. Secondly, they're both competing with small, secure, engineered-for-security programs written by Dan Bernstein, qmail and djbdns, which is what this thread is about.

  • Re:No real explanation of fees (Score:1)

    by Anonymous Coward
    Split the code. But he's already made plans for that I bet. This wasn't the first big nasty from Vixie and it won't be the last.
  • His software *would be* a viable alternative if linux distributions would start caring more about performance and security than they did about branding.

    Alas, that will never happen. So, we poor admins are forced to actually compile something. The humanity.
  • It isn't at all scary. Considering the frustration I've with Amiga Inc's closed source SDK missing minute BUT FUCKING important features WHICH I CAN'T ADD because Tao owns 15% of Amiga and they're closed morons.

    I could save Amiga's ass with very little work but I CAN'T. I am not allowed to.

    You expect me to deal with that kind of frustration in BIND?

    ARE YOU MAD?

    I have a question for you.

    What's with this need to speculate and guess and pontificate whenever something happens? Whatever happened to principles like only criminals will have the tools to defend themselves?

    Admit it. You don't know. And you're making it even worse by guessing at their intentions.

    How about asking both sides what they think?
  • So your saying it is only a quantatative difference and not a qualatative difference. "You could act like not knowing the latest hole in BIND is more dangerous than driving an asbestos-insulated Yugo without seatbelts at 115 MPH through L.A. during rush hour while smoking unfiltered Camels, but it's not." Could you please clarify what you were tring to say?
  • Very good point. I think that there are other good reasons to fork or have competing implimentations, but this is an excellent one.

    We don't, however, have to go all the way back to the potato famine to see the damage that this sort of heterogeneous community has. Take a look at the damage that the infamous Morris Worm wreaked. It only knew how to exploit sendmail and either ftpd or fingerd on Suns and VAXes....
  • True, but there are a lot more people than just plain old end-users who read /.

    To lots of server admins, and other people concerned with security issues, this is not a trivial story and counts as "stuff that matters".

    siri

  • Perhaps some of the larger players, ie. a few certain companies that have had oh so public problems with their dns, could throw some support behind the cause. We can fork until the cows come home but without proper planning and support, in the end we'll be back to square one.
  • "Having bind run as a non-priviledged user would have greatly minimized the security
    breach. The very fact that bind doesn't do that leads me to believe that it is insecure by design. "

    So why not stick `-u named' on the end of the command?

    Chrooting *is* a jolly good idea for all daemons you're going to be running. But bear in mind that you can break out of a chroot jail, even easier still if you're running as root within it. (I've not read so much about it, but look into shared library requirements and that sort of thing.)

    Also remember that prior to 2.2.16, any process calling setuid() could return to being running as root by breaking capabilities, anyway.

    ~Tim
    --
    .|` Clouds cross the black moonlight,

  • Alternative DNS server under GPL license (Score:2)

    by Anonymous Coward
    Get it here [kyuzz.org]
  • Since qmail has already had one exploit in its history...
    What exploit are you referring to? To my knowledge there has never been a remote-root exploit for qmail (and securityfocus doesn't show anything like it, either). The closest "exploit" has been a denial-of-service attack that was based on overly-long RCPTs in SMTP handshakes. This never compromised the security of the host but only caused qmail to stop responding to SMTP requests.

    Contrast qmail's security history -- with only one, non-compromising DoS vulnerablity -- to sendmail's -- chock full o' root holes -- and you'll see that there is no comparison between the two.

    ... why should we believe that the rest of DJB's software is any more secure?
    Don't trust anybody's reputation. Read the code. Compare qmail's code to sendmail's. Compare djbdns's code to BIND's. No comparision. Say what you will about the man, but djb codes with a paranoia that few can match.

    If security matters to you, read the code.

  • Um, yes it is. If this consortium produces a fix, they don't have to release it in binary form, and therefore don't have to release it in source form either. All the GPL says is that if you release binaries, you also have to give the source to anyone who has the binaries if they ask for it.
  • You have good reason to be nervous. Even a hint of supression and you would be safer if the exploits were published before the fixes!

  • Code forks, monoculture and kindness toward others (Score:5)

    by mellon ( 7048 ) on Saturday February 03, 2001 @01:28PM (#459218) Homepage
    BIND 4 and BIND 8 are widely acknowledged, not only by people outside of ISC, but by people inside of ISC, as a maintenance nightmare. This is why the ISC rewrote BIND 9 from scratch. So if you want to do a code fork, I think it would be better to start from, e.g., BIND 9 than BIND 4/8. But I really hope that there won't be a code fork.

    With respect to monoculture, there are at least four DNS server implementations out there - BIND 4/8, BIND 9, djbdns and Microsoft. If you're afraid of the BIND monoculture and you're running BIND 8, you do have alternatives. Personally I run BIND 9 on my alpha, which takes care of the monoculture issue for me. :')

    With respect to questioning Paul's motivation, please think carefully. Paul and the ISC are supporting BIND 8, even though we have a code base that's much more supportable in BIND 9, because he knows that not everybody can just up and switch to BIND 9 right away.

    It's a lot of extra trouble to support BIND 8. Nobody wants to do it. Nobody wants to pay for it. You heard from the guy at Mandrake - he's offended that anybody would even suggest that they could contribute monetarily to the maintenance of BIND 8. Despite this, when problems crop up with BIND 8, we do our best to fix them in a timely manner, with a very good track record so far.

    I don't know if the proposed revenue stream will amount to enough to hire an engineer, but maybe it will. As far as I can see it (and I'm not an insider on this because I'm a DHCP hacker, not a BIND hacker), the proposal doesn't change when problems will be announced to the public. Paul was quoted in this article as saying that the ISC was interacting with vendors through a private channel (CERT) about this bug - just not a very handy private channel.

    Even so, the CERT advisory andthe fixed versions of BIND 4 and 8 came out before the BugTraq advisory. You can argue about whether or not the ISC did the right thing in not announcing the exploit on BugTraq before there was a fix, but what the ISC did looks pretty ethical to me, and it looks like the Open Source community got a pretty good deal.

    Naturally I'm a bit biased, but frankly after all the work I put into ISC software, and all the work I know Paul puts into it, not to mention the work all the other ISC people do, it's kind of sad to see how willing folks are to accept the idea that we're rotten incompetent villains out to make a fast buck at the expense of our peers.

  • Banks used to hide their vaults from the public. You had to be have a safe deposit box or be an employee to even see the vault. In new bank construction, the vault is usually visible to the street through the glass doors or storefront.
    People planning serious physical security always assume that the attacker has complete knowledge of the defense and its weaknesses. For example, I once read a book by the Nuclear Regulatory Commission which specifies physical security barriers for nuclear plants. Each type of barrier (for example a 10" thick poured concrete wall) has a rating in minutes. This is the number of minutes to penetrate it with the best technique, whether that technique is explosive, gas-powered saw, cutting torch or whatever. This lets them plan security rationally and not have their plan disintegrate because some piece of info was leaked.
  • It seems like his server doesn't even support TCP queries! Simply throwing up your hands and saying you should never get a response larger than 512 bytes is a stupid cop-out.

    And simply making assumptions without reading any documentation isn't a "stupid cop-out"? Of course djbdns supports TCP queries. dnscache (the caching resolver) listens on UDP port 53 and TCP port 53. tinydns, the authoritive nameserver, listens only on port 53, BUT, if you get near the 512 byte limit (which you really shouldn't), you can run axfrdns under tcpserver which will serve queries on TCP port 53.

  • And the solution is to let the moron's who wrote the fucked up code in the first place, to work on it secret?
  • Yes, it is better to assume full knowledge when designing security systems, but that doesn't mean that we should do our damndest to make sure as many people as possible have full knowledge. This is what public disclosure does. If I find a security flaw in a peice of software, publicize it, and some jackass uses it to crack a server or something, I am partially responsible, aren't I. If a parent leaves a loaded gun on a table and their young child kills himself or his sister, then the parent is certianly legaly responsible. How is this different?
  • Open source security doesnt claim to prevent bugs or holes, it claims to get them fixed faster. Just like whitehat hackers. Lets see: Privateonly list reveals bug in bind. people on the list fix servers they own, maintain. Prepare for a fix in the next release.
    The millions of sites not on the list still have the hole, dont ever upgrade bind because there is no bug known...and stay that way for a while...meanwhile they are experiencing unexplained bugs and attacks.

    OR:
    Hole is found and documented, everyone can access this info, sysadmins fix their servers in fear, some sites go down because the admins arent doing their job.
  • The port is bound after starting threads because it can't be bound until after the config file is read, since the config file specifies the ports to listen on. The config file is read after threads are started for several reasons, not the least of which is that it's also read with threads active in the reload case.

    With bind 9 on linux, a chroot jail cannot be broken out of using those steps, since the CAP_SYS_CHROOT capability is dropped.

    If you want setuid on a 2.4 kernel, compile with --disable-threads.
  • LinuxThreads aren't different, but under 2.4, capabilities can be retained across setuid(). So, named can call setuid() early (that is, before threads start), while retaining the ability to later bind port 53.
  • The slashdot party line, and the open source party line in general, seems to be that security through obscurity doesn't work. It's better to be open source and have people help you find bugs early, and get rid of them.

    Apparently it's not working. I realize that, as the primary unix nameserver, it's very dangerous when a new bug comes out in bind. Millions of sites probably run bind, and they're all vulnerable to the latest bugs. This is obviously bad.

    But doesn't going to this private-group model for security information show that the open source security model really doesn't work for important, widely used applications?

  • And djbdns only implements a subset of what BIND 9.1.0 offers. Things like DNSSEC, have little to no hope of being implemented in djbdns because Mister Bernstein doesn't believe it to be of any use. It also has a rather nasty license policy:
    You are permitted to distribute a precompiled djbdns package if
    • installing the package produces exactly the same files, in exactly the same locations, that a user would obtain by downloading, compiling, and installing dnscache-1.00.tar.gz or djbdns-1.01.tar.gz or djbdns-1.02.tar.gz or djbdns-1.03.tar.gz or djbdns-1.04.tar.gz;
    • the package behaves correctly, i.e., the same way as normal djbdns installations on all other systems; and
    • the package's creator warrants that he has made a good-faith attempt to ensure that the package behaves correctly.
    It is not acceptable to have djbdns working differently on different machines; any variation is a bug. If there's something about a system (compiler, libraries, kernel, hardware, whatever) that changes the behavior of djbdns, then that platform is not supported, and you are not permitted to distribute binaries for it.
    In short, you're allowed to distribute binary or source versions if and only if you distribute it exactly as he wrote it and distributes it on his site. These kind of conditions are why you don't find Pine and qmail in Debian's archives in anything other than source format, forcing you to compile it manually with diff patches if you want it to integrate properly into the Debian system. Because of this, I have some serious doubts that djbdns will catch on.
  • You are all *completely* missing the point.

    EVERYTHING THAT IS CURRENTLY PUBLIC WILL REMAIN PUBLIC AND WILL BE RELEASED ON THE SAME SCHEDULE THAT IT ALWAYS HAS.

    Certain information which is private *NOW* will be made available to people who have a plausible, legitimate, reason to want to have it *even sooner*. Access to the CVS tree, stuff like that. Stuff that *no one* gets right now on any kind of formal basis.

    No one is talking about not releasing bug fixes in source, or not releasing bug announcements *exactly* when they are released now.

    They have *always* waited, whenever possible, until a fix is known before releasing a bug discovered through auditing.

    There's nothing, at all, worth complaining about here. This isn't "security through obscurity". This is "let's make the internal discussion about how to handle a bug a bit broader so that vendors who need to be involved early can do so".
  • The "free" in free software refers to freedom, not free of charge. You are free to copy the software. That's free. If you want high-quality, responsive support (i.e., not what you get on the free mailing list), you may be asked to pay for it. Does RedHat ship you CDs for free? No, but they do let you download the software for free. Same deal with ISC, only the thing for which we charge may turn out to be different. *shrug*

  • Code fork or replacement coming... (Score:5)

    by ajs ( 35943 ) <ajs.ajs@com> on Saturday February 03, 2001 @09:38AM (#459230) Homepage Journal
    Looking at the responses in the article, this one was pretty much a summation of the (more verbose) others:
    Security Admin (security@cyberlink.ch)

    VERY harmful. This is screaming for a code-fork, for the same procedure that happend with SSH. If ISC doesn't back off, we're soon gonna have OpenBind.

    So, to me it's pretty obvious that this move is going to produce a fork. Someone does mention dents [sourceforge.net] which might provide another path entirely....

    The operative question is: Is this a good thing? I think the track record (ssh/openssh, RSA/PGP/GPG, GIF/JPG/PNG, UNIX/BSD/Linux, etc, etc) shows that the answer will eventually be yes.

  • Comment removed (Score:3)

    by account_deleted ( 4530225 ) on Saturday February 03, 2001 @09:39AM (#459231)
    Comment removed based on user account deletion
  • If a parent leaves a loaded gun on a table and their young child kills himself or his sister, then the parent is certianly legaly responsible. How is this different?

    Mostly because nobody fucking DIES when Yahoo or eBay goes down for a couple hours.

    Yes you can yammer about how much DoS attacks and server downtime cost the economy, and make bad analogies about bank vaults guns, and Microsoft. You could act like not knowing the latest hole in BIND is more dangerous than driving an asbestos-insulated Yugo without seatbelts at 115 MPH through L.A. during rush hour while smoking unfiltered Camels, but it's not.

  • If a parent leaves a loaded gun on a table and their young child kills himself or his sister, then the parent is certianly legaly responsible. How is this different?

    Because that analogy isn't even vaguely applicable.

    First of all, if you find a security flaw, you have no way of knowing that you're the only person to have done so. Chances are you're not. But some of those people will keep it to themselves, to use for their own purposes which are probably not constructive.

    Secondly, you're completely ignoring the actual point of releasing this information, which is to give people who use the flawed product some way to protect themselves. With knowledge of the flaw, they can take measures to make sure they're not attacked. Without this knowledge, they are at the mercy of the other people who have discovered the problem.

    I will say this: Making this information available benefits experienced and competent system administrators, to the detriment of the less knowledgeable (who may not have the means to protect themselves against the problem, and may therefore find themselves under attack by copycat exploiters). However, since being or hiring experienced administrators is a socially beneficial act, it is to be encouraged through this and any other measures, especially when better overall security is the main dividend.

  • He is no more fucking ORBS than Linus is fucking Bill.

    Producing a superior product is not called "fucking", it's called "innovating".

    ...now, if we could just teach the USPTO the difference between "innovating" and "fucking", the world might actually be a nice place.

    --

  • djb doesn't release his work under a proper opensource license, so most distributions want nothing to do with his software. Thus djbdns is not a viable alternative.

    It may make it a tricky alternative for distributors (who have to supply the original plus patches rather than a modified original), but that doesn't mean it's not a fine alternative for savvy admins whose needs it otherwise meets.

    Qmail is saddled with the same restrictions and is used by many of the busiest mail sites on the net (Hotmail, Critical Path, Yahoo, the spam-magnet server in my house, etc.). Surely there's some hint of viability in there.

  • Replacing BIND involves creating a program that properly implements a number of well defined protocols. Replacing the Internic involves convincing everyone running DNS on the Internet to switch to a different set of root name servers. Both tasks are technically feasible, but one of those tasks is extremely unlikely due to political reasons.


    On the other hand, if you could convince Redhat, SuSE, Mandrake, Sun, and the *BSD distributions to ship with your new root nameservers in their default named cache, you would probably be most of the way to highjacking DNS since many admins wouldn't be bothered to notice the difference (and the remainder might be willing to give you the benefit of the doubt if your reliability and response time was as good as Internic's). Convincing all those vendors might be a little tough, but it's more likely than convincing hundreds of thousands of sysadmins.
  • no this is like an ATM if I want money I go to the ATM and say give me money and it does but it doesn't give me othe peoples money or more money than I have it just gives me money and if we stick the ATM in a brightly lit store where there are people all the time it is more likely to net get robbed of broken into , so I believe your analogy is totally incorrect Jon
  • In other words, "why not have security through obscurity in addition to real security? This is what the military does. The answer is that only a very disciplined organization can do this effectively. For example, the NSA has internal teams that attack their products with full knowledge of the design. Then they get an additional safety factor by keeping the design secret.
    Out here in the 'real world', though, security through obscurity leads to laziness - people are generally unable to act as if the design is public when it's secret. And yet the secret design has probably been leaked.
    Leaving aside the fact that the parent is responsible for the kid's welfare, I don't think we can compare publishing research results to furnishing a physical object. Suppose Alice is the CEO of an overvalued company. Bob, an analyst, explains why it's overvalued and suggests that investors sell. Investors sell and the stock price plummets. Did Bob do something wrong? I don't think so.
  • ...but Im tired of updating BIND every once in a while. If a fork would produce a much higher quality software to do the job, then fork the damm think.

    I think is way too much responsibility for the ISC to do such an important piece of software for the Internet and to be by far the most used.

    All that Im trying to say is that there should be others open-source/GPL choices of software for this task.
  • I have had similar thoughts, myself. I liken it to a safe. You use a safe for strong physical security, but most people hide a safe, because you have to know where it is in order to crack it. Most people don't tell everyone they know where their safe is and that it has a specific weakness that makes it easily crackable. But this is what this full-disclosure philosophy wants people to do. I just coneptualize to extremes of security. At one end is am enormouse bank vault that has 10 foot thick titanium and concrete walls. This is put in a public place and the location is advertized heavily. On the other end is hiding some money behind a picture in a frame. You tell no one about it. So I am getting that the latter is "no security at all" Hell, common sense says that the more people that know about a flaw, the more that will try to use it. Oh no, you say, but more people will also try to fix it. But how does this apply to close sourced operating systems?
  • irish potato famine?

    saying there was not enough food grown in ireland to feed the population during the "potato" famine(s) is like saying the armenians committed mass suicide in 1918.
  • bind 8 doesn't have to run as root. If you start bind (named) with "named -u uid" it runs as the specified uid. This can be changed in your /etc/init.d startup file for automatic startup. Just make sure your bind cache files are readable and writable by bind:

    $ ls -ld /usr/local/named
    drwxr-xr-x 5 named named 4096 Jan 31 17:13 /usr/local/named/
    $ ps -ef |grep named
    named 577 1 0 Feb02 ? 00:00:54 named -u named

  • Because bind author's don't like Linux' threads (Score:5)

    by BlueUnderwear ( 73957 ) on Saturday February 03, 2001 @10:26AM (#459243)
    > Why does bind run as root?

    Quoted from the bind9 FAQ:
    Q: Why doesn't -u work on Linux 2.2.x?
    A: Linux threads do not fully implement the Posix threads (pthreads) standard. In particular, setuid() operates only on the current thread, not the full process. Because of this limitation, BIND 9 cannot use setuid() on Linux as it can on all other supported platforms. setuid() cannot be called before creating threads, since the server does not start listening on reserved ports until after threads have started.

    My take on this:

    Then why the hell do they do the setuid() call so late in the process? Just do it right after binding the port, but before forking any threads. Why the hell does that port have to be bound after starting threads? It's shared by all threads anyways, so why not bind it early?

    > But some people have suggested that it is possible for a process to get out of chroot. Can somebody please elaborate?

    If a process still has uid 0, there are several ways to break out of chroot:

    1. make a subdirectory foo
    2. chroot into it (without chdir'ing into it...): Current directory is now above root... Indeed, the chroot syscall only changes your process' root, but does not automatically change its current directory.
    3. repeatedly chdir("..");. This works because chdir only checks whether your current directory is equal to your root, it does not check for the case where it is above the root.
    4. once arrived at the physical root, chroot("."); and presto, you just broke out of the chroot jail
    Even if this hole was patched (AFAIK, it exists in all Unix variants...), it would still be possible to break out of chroot by fiddling with raw devices such as disks and /dev/kmem. Conclusion: chroot() can only be used in conjunction with setuid() to a non-privileged user. Chroot makes it difficult for a non-priv user to gain root, but it doesn't protect anything if ever the user succeds to gain root anyways...
  • I need source to fix it.

    It isn't all like a safe. It's like a tire.

    I need a knife to cut a tire. I need Firestone's trade secrets to fix it.
  • Because they're both 1) widely used, and 2) have had remote root exploits.
    -russ (webmaster@qmail.org and webmaster@djbdns.com)

  • >just another typical slashdot knee-jerk witchhunt that is completely unfounded.
    Maybe that's why I read /. (at -1 yet).
    I have no problem with giving the authors a bit of time to fix the problem before making it public, but I know that I would much rather read about a potential problem that experience it first-hand. Keeping bugs and exploits secret doesn't really work very well.
  • A damn good idea.

  • A good take on this? (Score:5)

    by labradore ( 26729 ) on Saturday February 03, 2001 @10:48AM (#459248)
    Mr. Vixie has been a little vague.

    In trying to read his email and interview in the best-possible light I think that his bind-members mailing list proposal may not really be a bad thing for the internet community. We all rely on Bind and we all rely on mostly the same sources of information about vulnerabilities and vulnerability fixes (CERT, bugtraq, ISC-patches for Bind, etc).

    I think what Mr. Vixie has said can be read this way:

    Some vendors have ISC-derived private code. They want some support for their code from the ISC and they want to discuss fixing their closed-source Bind-derivatives in a closed forum (thus the NDA's and PGP encryption on the mailing list). The bind-members list will become that closed forum. New CERT advisories and ISC's own vulnerability discoveries will still be posted and available in open forums at the same time they are available to the closed forum. However, information that only applys to the closed forum will stay inside the closed forum.

    If that "spin" is correct then the closed forum members will be subsidising the ISC's development efforts (on a regular basis) and getting privacy for their money.

    I think there aught to be a parallel open forum for the free software Bind derivatives and distributions for posting bug discoveries and bug-fixes.

    While Vixie's proposal is not strictly a bad thing we won't know if the closed forum is sticking to their stated mission. I think the real solution is to start development in the spirit of Mr. DeRaadt's comment: re-develop bind into task-oriented, well defined subcomponents. Large "hub" nameservers and root servers will use more components than small local nameservers and caching-only nameservers will use fewer still.

    The development of this new nameserver daemon should be under a Free software liscense (GPL(!!)).

    Then again, I could be wrong....
  • I've discussed this with a few admin partners and the BIND problem is something that always takes significant amounts of time to stay on top of. Seems the timing is right for either a code fork, or more effort on alternatives. I don't like the licensing sound of dbj-dns [cr.yp.to], so I don't think that's the answer. It's not really clear what the license is.

    Something that has an application front-end with a database back-end would provide better security and other features. The dbase could be replicated to off-line servers for redundancy in case of faults. This could also be used for load-balancing and backups as well. The front-end for administration could be web-based with a php or perl api for ease of expanding the application. I'd be interested in seeing active development on this project and would definitely contribute. Note that MySQL [mysql.com] is GPL, so the potential for this type of thing happening again would be eliminated.

    Linux rocks!!! www.dedserius.com [dedserius.com]

  • Since qmail has already had one exploit in its history, why should we believe that the rest of DJB's software is any more secure?

    maru
  • When anyone imitates MS's security tactics (ignore, deny, obviscate and cover up) there is going to be a problem. It saddens me that such an important piece of "Internet software" such as bind is taking this route. I just wish there were some better alternatives taht interoperated with bind. I predict if the "members only" security list and the hog wash that will go with it comes to pass, bind will slowly die as people look for better, smarter software.
  • Someone has to make the obligatory /. type response (tongue in cheek) about the danger of a heterogeneous community, I mean running Outlook on Windows, and waiting for ILuvU2 or Daughter of Melissa....

    More seriously I agree that this increases the likelihood of a code fork unless it's abandoned.
    ----

  • Please do not consider this flame-material, but such a fee-based consortium is not possible under the GPL. Vixie poo-poos the GPL, but as we generally regard closed-BIND as bad, this clearly is a case in favor of GPL'ed source. Thoughts?
  • Since qmail has already had one exploit in its history, why should we believe that the rest of DJB's software is any more secure?
    Out of curiosity, which exploit were you thinking of.. is it one of the DOS attacks [cr.yp.to], or the overflow bug in the third-party [cotse.com] vpopmail add-on? (Wait, maybe you mean this one [omnipotent.net]!)

    To answer your rhetorical question, I don't think anyone believes that djbdns is inherently more secure than qmail (although it is a lot easier to configure qmail in an insecure way, if for no other reason than that it's capable of running programs from .qmail files). I trust both of them a lot more than I'd ever trust BIND, though, even if that isn't saying much at this point.


  • Isn't the author of , a with many past security problems?

    maru
  • Curb some of your projection of context.
  • Pardon me, but exactly WHY is it not appropriate to fix a hole in the street if it annoys the heck out of me, and if I know, that when I don't do it, noone may do it?
    I fail to see the bad side of this?!
    I much rather think, that this would be a positive attitude. Just imagine, how many millions of tax DMs/Dollars/Pounds/... could be saved, if everyone did this. And also think about how fast this would fix all the streets.
    Sorry, but I think that this would be a good rather than a bad attitude...
  • I don't suppose djbdns support Dynamic DNS, DNSSEC, or any of the other goodies that BIND does? I really wish I could switch and try it, but some of us have to at least TRY to deal with the Win2000 Active Directory weenies. Besides, DJB's whole notion of breaking these things up into seperate programs is just weird. To replace BIND I'd need to install at least 5 or 6 of his different programs of which I have no guarentee they'll even perform with the same functionality. It seems like his server doesn't even support TCP queries! Simply throwing up your hands and saying you should never get a response larger than 512 bytes is a stupid cop-out.
  • Stupid analogy, no. Slighltly off the mark perhaps.

    But think for a minute. Are you suggesting technicians who don't have Firestone's Trade Secrets or the right to discover those secrets would be able to find what caused those tires to explode.
  • This is just a common fallacy. Look at qmail. Its security guarantee has been around coming up on 5 years now and has gone unchallenged. Sendmail has about 47% of the market share, with qmail around 11%...qmail may very well deliver more Internet mail messages than sendmail (sendmail has such a large share because it's the default install on most OS's). Who would you rather trust? The BIND company who can't seem to get things right, or an author who obviously knows what's up based on his other software (not to imply that djbdns cannot stand on its own--it's been around for about a year now)?
  • From what I read from the article itself is that what they are trying to create is a forum that the People who are responsible for fixing the bugs can openly discuss the exploits and fix them before it becomes public knowledge. I doubt they would say that it was wise to move to a "closed source" model.

    In fact, Paul said that they were going to continue to distribute code in the same way they always had - which I take to mean including source that anyone can look at. I doubt there will be much change in the way 99.9% of the community interreacts with Bind and ISC.

    Today, what happens is that someone finds a bug, ISC gets told about it, and then they FIX IT IN PUBLIC, while thousands of script kiddies run around and try the exploit on machines that don't even have a patch available yet. Even Microsoft is usally given the opportunity to fix major security bugs prior to them being posted publically on Bugtraq. Why should ISC be any different?

    From the bugtraq faq:

    A sensible protocol to follow while reporting a security vulnerability is as follows:

    Contact the product's vendor or maintainer and give them a one week period to respond. If they don't respond post to the list.

    If you do hear from the vendor give them what you consider appropriate time to fix the vulnerability. This will depend on the vulnerability and the product. It's up to you to make and estimate. If they don't respond in time post to the list.

    If the contact you asking for more time consider extending the deadline in good faith. If they continually fail to meet the deadline post to the list.

    Now, assuming that people DO this, where today can ISC discuss and fix the bug in private? I think having a list with only selected individuals on - specifically the ones Vixie mentioned, including the people who maintain bind for the major Open Source Distributions (FreeBSD, Linux, etc.) - where they can prepare fixes prior to CERT releasing the information and (hopefully) prior to it being seen on bugtraq.

    I'm not sure the reason behind the fees. Perhaps it is to help pay for the additional coordination required for doing this. Perhaps it's just to keep the script kiddies out.

    I'm also not sure about the private access to the CVS database. This is the only part of this that concerns me. I can think of several reasons why this might be a good idea. Does anyone know if you can get a hold of the CVS database today?

  • ==
    Something that has an application front-end with a database back-end would provide better security and other features. The dbase could be replicated to off-line servers for redundancy in case of faults. This could also be used for load-balancing and backups as well. The front-end for administration could be web-based with a php or perl api for ease of expanding the application.
    ==

    Have you ever administered a name server before and do you have any idea how one operates? The "back end database" idea is not displaying a real insight as to the development issues posed by a name server, it's not like resolution requests can be queried against the database so the storage model is not real relevant. It all has to go into memory. The request for an administrative GUI is equally short-sighted. I have administered NT-based DNS systems that used GUIs before and changing IP information on 300+ domains was a real mouse-killer.

    maru
  • Not sure what the fsck happened with that previous post, it previewed fine. Was supposed to read:

    He isn't the author of [insert the name of any widely used *nix-based software that is 10+ years old] , a [insert application use] with many past security problems?

    maru
  • This is what I really don't get. Bind needs root permissions only to get access to port 53. After that, why doesn't it give up root permissions, like Apache?
    If UNIX/LINUX treats everything like a file, why not TCP/IP ports, too? That way, you could assign a port to a group/user who could access that port without being root!!!

    --

  • I run four nameservers, and all four run BIND 8.2.2. I've always been aware of BIND's history of bugs, and BIND's history of having those bugs found and fixed quickly. I don't stay awake at nights worrying that someone is going to break in to my nameservers. However...if I'm not able to see the same information as everybody else, that's going to make me a lot more nervous about running BIND at my business. If this trend keeps up, I'll seriously look in to alternatives. However, it's not like ISC is going to lose money by my changing or anything. What do they care if they irk some random Unix sysadmin?
  • I haven't worked yet with Bind9.

    But, I have deployed 8.2.x extensively, and I run Bind as user "named" or "dns" as a matter of course.

    If Bind9 can't be run securely on Linux--and I don't think LinuxThreads are materially different in 2.4--then Bind9 may just be where I get off the train.

  • Re:Code fork or replacement coming... (Score:3)

    by Anonymous Coward on Saturday February 03, 2001 @09:57AM (#459276)
    The operative question is: Is this a good thing? ... the answer will eventually be yes.

    I agree, but for a slightly different reason.

    Remember the Irish potato(e) famine. It has been shown repeatedly that monoculture doesn't work well for stability and fault tolerance.

    Why were the recent BIND exploits increadibly serious? Because 99.99% of DNS servers use BIND. (Waring: Statistics made up.)

    If half the population used BIND, and the other half used OpenBind, when a security flaw is found in OpenBind (or BIND), only half of the DNS servers are affected. Additionally, if flaws are serious/ slow to be fixed, you can always switch to the other program.

    It'd be a rare exploit (most likely in the DNS protocol itself) which could take down two different DNS servers.

  • Um, no. You made a blanket statement, prepare to die.

    bind can be configured to run as nonroot in a chrooted jail easily, at least in version 9.1.0.

    named -u named -t /chroot/jail/named

    gets you started. Other versions I'm not so sure support running as user *blank*. Older versions don't, but the recent rewrite (9.1.0) does.

    chroot'ed directories can be escaped by root users doing chroot ../../../../../ from what I understand.

    --johnny
  • I agree, this is a very valid point, especially towards DoS-type attacks. However, I'd also like to add multiple different daemons have their own drawbacks, insofar as there is more potential bugs that can hit you. For instance, if you're running two different name servers on the same unprotected subnet, you might well have just doubled your exposure, since it only takes one bug to break your entire subnet wide open. Conversely, (towards your point) more singular cultures also increase the reward factor for would be hackers. In other words, if every site ran its own home brewed name server, the hacker would have to put in effort just to crack that one site. Smaller sites like, say, Edogpoo.com may enjoy a poor cost benefit relationship, from the would-be hacker's perspective.

    The bottom line is that there are oppositional forces and tradeoffs, like so many other things in security and in the computing world. One setup is not always the best, it depends greatly on the entirity of the situation.
  • It is not acceptable to have djbdns working differently on different machines; any variation is a bug. If there's something about a system (compiler, libraries, kernel, hardware, whatever) that changes the behavior of djbdns, then that platform is not supported, and you are not permitted to distribute binaries for it.

    I think that the reason he uses such draconian language is that he wants to ensure that any modifications by a programmer will not make djbdns less secure. I think it would be pretty easy for any new code to make his code less secure, if for instance, you were to add a system call using data from a remote machine.

    Also if porting to a different machine there may be other architectural/security considerations to keep in mind and trying to force djb's code to fit into that computer architecture may break its security model. That's probably why the license is the way it is.

    He does give you the option to send him a request for license specifics if perhaps you might want some leeway but that would be on a case-by-case basis.

  • Why are you guys so worried about this anyway? This certainly doesn't stop anyone from publishing the exploits on Bugtraq AS THEY DO ALREADY. You'll get the same information at the same time as everyone else. This just gives the authors a bit more time to patch their code when someone brings a bug to their attention. Bugtraq has that same policy with closed source companies' operating systems and products. Inform the vendor, give them time to patch it, then release the information if they don't fix it within a timely manner. What's so bad about giving ISC and the BIND group the same priviledges? I think this is just another typical slashdot knee-jerk witchhunt that is completely unfounded.
  • I can't find the indicated bind9 FAQ, but I just checked my installation of BIND 9.1.0 (which starts named with '-u daemon') and confirmed via 'ps x' that all named threads are in fact running as user 'daemon'. This is with kernel 2.2.18 and Glibc 2.2.1.

    Looking at the bind 9.1.0 sources, specifically bin/named/unix/os.c, it appears that the BIND authors have hacked around the pthreads problem using capabilities. The main thread does setuid() early-on, so as to propagate the new uid to its child threads, but reserves for itself the capability to bind to privileged ports. This allows named to launch its child threads before it decides what ports to listen on.

    My only problem with this approach is that I don't see where named eventually drops the privileged-port capability later.

  • Zebbers makes it so clear and basic why open source is the right way to go and incompetent administrators should be fired.

  • Combining open source with closed information is what will fail. The only way closing the bug reports works at all is if the source is also closed. Otherwise l33t cR4q3rz who can read source can find bugs and distribute exploits (w/o NDAs), and admins who can't (read source) won't be able to fix things, all the while the members get to sit on their own lazy asses because they got them covered.

  • Re:Fucking ORBS? (Score:3)

    by Skapare ( 16644 ) on Saturday February 03, 2001 @02:58PM (#459292) Homepage

    Closed bug reports only work with closed source. It's just a matter of time before Vixie closes BIND, or at least the leet version of it that members get to use.

  • Time for djbdns... (Score:4)

    by tmoertel ( 38456 ) on Saturday February 03, 2001 @09:58AM (#459294) Homepage Journal
    Looks like it's time to replace BIND with djbdns [cr.yp.to].

    Djbdns is to BIND what qmail is to sendmail. Not only is it written with security in mind, it even has a security guarantee. [cr.yp.to] A refreshing change of pace.

  • If UNIX/LINUX treats everything like a file, why not TCP/IP ports, too? That way, you could assign a port to a group/user who could access that port without being root!!!

    Ahh, yes. Somebody finally noticed. Unfortunately TCP/IP was not added to UNIX until BSD in the 80's. So we have BSD Sockets and the "Everything is a File" mantra no longer holds.

    I believe that Plan9 [bell-labs.com], now known as Inferno [vitanuova.com], works this way. It was developed in the late 80's/early 90's by the original UNIX people at Bell Labs. Lucent (Bell Labs) has released Plan9 source under their own license, source and binaries can be downloaded here [bell-labs.com].

    Have Fun!

  • With respect to monoculture, there are at least four DNS server implementations out there - BIND 4/8, BIND 9, djbdns and Microsoft. If you're afraid of the BIND monoculture and you're running BIND 8, you do have alternatives. Personally I run BIND 9 on my alpha, which takes care of the monoculture issue for me. :')

    Don't forget Novell DHCP/DNS [novell.com], it comes with NetWare 5. There are more esoteric DNS servers listed here [dns.net].

  • No real explanation of fees (Score:4)

    by pmc ( 40532 ) on Saturday February 03, 2001 @09:59AM (#459297) Homepage
    The most troubling aspect of this is the proposal for fees. PV was asked about this, and this was the answer
    ISC has strong ties to vendors who run bind9, due to the vendor-funded project to write bind9 from scratch. however, ISC's contacts to vendors (or to the different parts of some of the same vendors) who run bind4 and bind8 are at the personal, 1-on-1 engineering level. it's now desirable to formalize and deepen the ties between ISC and those vendors or parts of vendors who are responsible for shipping BIND, and patches to BIND, as part of their products.
    To me that just doesn't make sense, particularly when later in the interview he says that he can't comment on the size of fees, but does suggest that there will be a scale of fees (as opposed to, say, a nominal flat rate). Even more strange is his suggestion that the fee can be waived for non-profit members when considered in the light of the reason for fees being to "deepen and formalize" the relationships.

    I feel that this whole mailing list looks like an attempt to generate a revenue stream through what boils down to blackmail: "if you do not pay us you will not get timely information about the security holes in BIND."

    This will (inevitably) lead to a code split, will be a very good thing: having practically the whole internet run DNS resolver (irrespective of how good it is) is dangerous.

  • Why does bind run as root? (Score:3)

    by RelliK ( 4466 ) on Saturday February 03, 2001 @10:01AM (#459298)
    This is what I really don't get. Bind needs root permissions only to get access to port 53. After that, why doesn't it give up root permissions, like Apache? Having bind run as a non-priviledged user would have greatly minimized the security breach. The very fact that bind doesn't do that leads me to believe that it is insecure by design.

    My second question is about running bind chroot'ed. I have seen the howto and it looks *very* useful for any daemon, especially bind in light of recent security problems. But some people have suggested that it is possible for a process to get out of chroot. Can somebody please elaborate?
    ___
  • Outside of server admins, what regular user even has to worry about this? Isn't this more a thing for BugTraq than Slashdot?

  • Re:Because bind author's don't like Linux' threads (Score:3)

    by BlueUnderwear ( 73957 ) on Sunday February 04, 2001 @01:34AM (#459300)
    > The port is bound after starting threads because it can't be bound until after the config file is read, since the config file specifies the ports to listen on. The config file is read after threads are started for several reasons, not the least of which is that it's also read with threads active in the reload case.

    Then, what would happen (in the non-Linux case) if the config was indeed reloaded, but a different low port was specified now? At that point, bind would already have dropped the privilege to bind to that port, and couldn't satisfy the reload request anyways. (Ironically enough, it would work on Linux, because you'd still have the capability to bind low ports...). Conclusion: changing port numbers on the fly wouldn't work anyways, so why not do a first parse of the config file before forking threads, and use this pass to gather those pieces of information which aren't changeable after reload anyways?

  • The phrase security guarantee is inapporpiate since noone can guarantee security. This is a security bug bounty.

    And 500$ is an insignifigant amount of money compared to the damage that a DNS bug can cause.


    --
    Remove the rocks to send email

Slashdot Top Deals

Talent does what it can. Genius does what it must. You do what you get paid to do.

Close