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

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.

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

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