Product
Solaris 10 Operating System

Bug Id
6532492

Date of Resolved Release
18-JUN-2007

Impact

A security vulnerability in Solaris 10 BIND DNSSEC may allow a local or remote unprivileged user the ability to cause the "named" BIND server process to exit (see also named(1M)). A Denial of Service (DoS) occurs as clients are unable to resolve addresses from or make dynamic updates to the server.

This issue is also referenced in the following document:

CVE-2007-0494 at: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0494

Contributing Factors

This issue can occur in the following releases:

SPARC Platform

• Solaris 10 without patch 119783-02

x86 Platform

• Solaris 10 without patch 119784-02

Notes:

1. Solaris 8 and Solaris 9 are not impacted by this issue.
2. Systems are only impacted by this issue if the BIND named(1M) service is configured for DNSSEC and is enabled.

To determine if DNSSEC is configured and enabled on a system, search for 'dnssec-enable yes' in the BIND configuration file "/etc/named.conf" by running the following command:

    $ grep -i dnssec-enable /etc/named.conf
    dnssec-enable yes;

To verify if the DNS service instance is enabled under SMF(5), use the svcs(1M) command as follows:

    $ svcs -l svc:/network/dns/server:default | grep enabled
    enabled      true

Symptoms

Should the described issue occur, the BIND server will not respond to client resolver(3RESOLV) requests. The "named" process may no longer be running, or it may be seen to be restarted erratically by the SMF(5) service.

In the following example, dig(1) is unable to contact the DNS server as listed in "/etc/resolv.conf," while the DNS server is still found to be otherwise alive:

    $ dig example.sun.com
    ; <<>> DiG 9.2.4 <<>> @192.168.0.1 example.sun.com
    ; (1 server found)
    ;; global options:  printcmd
    ;; connection timed out; no servers could be reached

On the DNS server, the state of the managed SMF instance may be checked by running svcs(1) command. For a full list of possible states, refer to the SMF(5) manual page. The following is an example depicting an online state:

    $ svcs svc:/network/dns/server:default
    STATE          STIME    FMRI
    online         16:24:04 svc:/network/dns/server:default

If the Start Time (STIME) is not as expected, it may be that SMF(5) is automatically restarting named(1M) after the DoS was attempted.

If the STATE is 'maintenance', then the service instance failed to start or remain running. Examine the instance log file for further details using the following command:

     $ tail -100 `svcprop -p restarter/logfile svc:/network/dns/server:default`

 

Workaround

To work around this issue until patches can be applied, disable DNSSEC functionality by setting 'dnssec-enable' to "no" in /etc/named.conf. Note this may affect the security of DNS transactions as the facilities provided by DNSSEC will no longer be  available.

Once the configuration file has been altered, the DNS service must be restarted by running the svcadm(1) command as follows:

    # svcadm -v enable svc:/network/dns/server:default
    svc:/network/dns/server:default enabled

followed by:

    # svcadm -v restart svc:/network/dns/server:default
    Action restart set for svc:/network/dns/server:default

Resolution

This issue is addressed in the following releases:

SPARC Platform

• Solaris 10 with patch 119783-02 or later

x86 Platform

• Solaris 10 with patch 119784-02 or later

The resolution above provides BIND 9.3.4 which implements DNSSEC-bis. After the patch has been installed, it is recommended that BIND administrators familiarize themselves with "/usr/share/doc/bind/migration.txt"

More information on BIND 9.3 and DNSSEC-bis is available in the "BIND 9.3 Advanced Reference Manual" (ARM), available on the ISC web site at http://www.isc.org/sw/bind/arm93/index.php.

References

119783-02
119784-02




Attachments

This solution has no attachment