Vixie And Others On Members-Only BIND Info

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.

Comments

Re:No real explanation of fees

[JCCyC]

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.

Code forks, monoculture and kindness toward others

[mellon]

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.

Code fork or replacement coming...

[ajs]

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 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.

Re:Code fork or replacement coming...

[Anonymous Coward]

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.

Re:security through obscurity?

[squiggleslash]

No, it shows Vixie et al are doing something that is likely to be opposed by most in the open source movement. An idea or principle is not proven or disproven on the basis of any group supporting or deciding not to support it.

What makes this all the more ridiculous is that this new system will allow anyone to find bugs, but make it difficult for anyone but a select few to push through fixes for them and publicise the problems. That's the worst of all worlds, no way of hiding bugs from black-hats, but a failure to take full advantage of the bug hunting capabilities of the majority.

It'll probably end up in tears. BIND will be discredited after several hacks that happen outside of the advisories, and other nameservers will be developed with a more open model.
--

Because bind author's don't like Linux' threads

[BlueUnderwear]

> 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...

Re:Because bind author's don't like Linux' threads

[BlueUnderwear]

> 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?

A good take on this?

[labradore]

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....

Re:Fucking ORBS?

[Skapare]

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...

[tmoertel]

Looks like it's time to replace BIND with djbdns.

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

No real explanation of fees

[pmc]

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?

[RelliK]

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?
___