[linux-security] bind remote root exploit

[Martin Siegert <siegert@sfu.ca>]

Topic
=====
remote root exploit in named (DNS name server)

Problem Description
===================
Problems exists in all versions of ISC BIND 4.9.x prior to 4.9.8
and 8.2.x prior to 8.2.3 (9.x is not affected).  Version 8.2.x contains
a buffer overflow in transaction signature handling code that
can be exploited by an attacker to gain unauthorized privileged access
to the system, allowing execution of arbitrary code.  BIND 4 contains
both a buffer overflow in the nslookupComplain() function, as well as
an input validation error in the same function.  These two flaws in
BIND 4 can result in a Denial of Service or the execution of arbitrary
code if successfully exploited.  Finally, both BIND 4 and BIND 8 suffer
from an information leak in the query processing code that allows a
remote attacker to access the program stack, possibly exposing program
and/or environment variables.  This flaw is triggered by sending a
specially formatted query to vulnerable BIND servers.

Affected Systems
================
All Unix systems that act as a nameserver and run the named daemon.
The client packages were ugraded as well.

Solution
========
upgrade to bind-8.2.3

RedHat 6.x
rpm -Fvh bind-8.2.3-0.6.x.i386.rpm bind-devel-8.2.3-0.6.x.i386.rpm bind-utils-8.2.3-0.6.x.i386.rpm 

RedHat 7.0
rpm -Fvh bind-8.2.3-1.i386.rpm bind-devel-8.2.3-1.i386.rpm bind-utils-8.2.3-1.i386.rpm

Debian 2.2 (potato)
upgrade to bind-dev_8.2.3-0.potato.1_i386.deb, bind_8.2.3-0.potato.1_i386.deb,
and dnsutils_8.2.3-0.potato.1_i386.deb

Mandrake 6.0
rpm -Fvh bind-8.2.3-1.3mdk.i586.rpm bind-devel-8.2.3-1.3mdk.i586.rpm bind-utils-8.2.3-1.3mdk.i586.rpm

Mandrake 6.1, 7.0, 7.1
rpm -Fvh bind-8.2.3-1.2mdk.i586.rpm bind-devel-8.2.3-1.2mdk.i586.rpm bind-utils-8.2.3-1.2mdk.i586.rpm

Mandrake 7.2
rpm -Fvh ind-8.2.3-1.1mdk.i586.rpm bind-devel-8.2.3-1.1mdk.i586.rpm bind-utils-8.2.3-1.1mdk.i586.rpm

Caldera OpenLinux 2.4
rpm -Fvh bind-8.2.3-1.i386.rpm bind-doc-8.2.3-1.i386.rpm bind-utils-8.2.3-1.i386.rpm
then restart the DNS name server (do this only if you had named running in the
first place!):
          /etc/rc.d/init.d/named stop
          /etc/rc.d/init.d/named start

Caldera OpenLinux 2.3 and OpenLinux eServer 2.3.1
rpm -Fvh bind-8.2.3-1.i386.rpm bind-doc-8.2.3-1.i386.rpm bind-utils-8.2.3-1.i386.rpm

Caldera has issued a fairly lengthy upgrade procedure for OpenLinux 2.3 and
OpenLinux eServer 2.3.1:

   As a matter of caution, we also suggest that you run the name
   server process under a non-root user ID. In case of future
   security holes in bind, this makes sure that remote attackers
   do not immediately obtain root access.

   Be warned however that when running the name server process
   under a non-root uid it loses the ability to automatically
   re-bind itself when you change the address of a network
   interface, or create a new one. If you do that, you need
   to manually restart named in this case.

   On eDesktop 2.4, named already runs under the "bind" account by
   default; this is not the case on OpenLinux 2.3 and eServer 2.3.1,
   however.

   Here's what to do:

   a.   Create a new user and group named `bind'.
        Pick an unused user and group ID (on a normal OpenLinux
        installation, uid and gid 19 should be available).
        Run the following commands as super user, replacing
        <uid> and <gid> by the user and group IDs you selected:

        # groupadd -g <gid> bind
        # useradd -u <uid> -g <gid> -d / -s /bin/false bind

   b.   Change the ownership of /var/named to bind.bind:

        # chown -R bind.bind /var/named

   c.   Edit /etc/sysconfig/daemons/named. Replace the line

                OPTIONS=""

        with

                OPTIONS="-u bind"

        This makes sure that the name server process relinquishes
        root privilege after initialization.

   d.   Stop and restart your name server:
        
        # /etc/rc.d/init.d/named stop
        # /etc/rc.d/init.d/named start
        
        Note that simply issuing /etc/rc.d/init.d/named restart
        will not be enough!