Re: Whom the BIND newest vulnerability concerns?
Sorry for bothering debian-devel; maybe I should have asked it on
debian-users instead... but I think that - as this approach seems useful -
developers could benefit too.
Russell, would you mind (if your free time allows it) describing possibly
in detailed way - how one could implement your solution, messing Debian's
files as little as possible. OK, I know how to add a "system" user for
this purpose :-) but later?
BTW, I've read something about running named in chrooted environment, but
it would probably require more changes - duplicating libs and so on...
--
Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only
tomek@lodz.tpsa.pl http://www.lodz.tpsa.pl/ | ones and zeros.
On Fri, 12 Nov 1999 at 14:10:25 +0100, Russell Coker wrote:
> >the slink (stable) version of bind (1:8.1.25) is relatively old and -
> >according to
> >http://www.isc.org/products/BIND/bind-security-19991108.html
> >- it contains a few security bugs.
> >The newest vulnerability _may_ lead to remote root compromise.
> >
> >Is a corrected package expected?
> >
> >I'm a little scared of this latest bug... It is connected with "the
> >processing of NXT records". I haven't managed to find a clear description
> >of this type (NXT) records; seems this is quite new type.
> >
> >So my concern is: if a server has _not_ such records in its own files, is
> >it vulnerable?
>
> It seems to me that bind is a package which is the subject of regular
> security alerts, many of which involve remote root access.
> I think that given it's history it can be considered irresponsible of an
> administrator to run such a program as root.
> On the machines I maintain I run bind as user "named" (UID 53 for
> conveniance). I use "sudo" to run it as non-root and "authbind" to allow it
> to still bind to port 53.
>
> Can the people who make the policy please consider putting in place a policy
> regarding packages which often have security problems. If such a package can
> be run as non-root then IMHO the default proceedure suggested by policy
> should be to run in that fashion.
> While we are at it, for most usage sendmail can run as non-root. Could we
> have it default to non-root too?
>
> On the systems that I run the worst possible outcome of the bind bugs would
> be DOS and/or corrupting the cached zones. The only files that the named
> user is allowed to write are in /var/cache/bind... If the named account was
> compromised to the level of gaining shell access then the attacker could run
> a new name server with fake data for the primary zones too (IE it could be
> configured to have primary zone files under /var/cache/bind). But that's
> still way better than having them take over the entire system.
>
> --
> Electronic information tampers with your soul.
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: