[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.2­5) 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: