Re: Whom the BIND newest vulnerability concerns?
>the slink (stable) version of bind (1:8.1.25) is relatively old and -
>- 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 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.