Security Vulnerability in Solaris 10 BIND DNSSEC May Cause a Denial of Service |
|
| Category : | Security |
| Release Phase : | Resolved |
| 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:
- Solaris 8 and Solaris 9 are not impacted by this issue.
- 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.
AttachmentsThis solution has no attachment