Re: Whom the BIND newest vulnerability concerns?

[Russell Coker <russell@coker.com.au>]

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