Ubuntu
bind9 package

Comment 3 for bug 406122

Revision history for this message

In Red Hat Bugzilla #514292, vdanen (vdanen-redhat-bugs) wrote on 2009-07-28:

A Debian bug report [1] notes that named can be caused to exit with an assertion failure due to a particular update packet. This will cause a complete exit of named, preventing it from serving any more DNS responses.

The bug includes a reproducer in perl that can be used to trigger this. I have tried the reproducer against my local network LAN server (running CentOS 5.3) and it works as advertised, however there are a few factors that increase the complexity and reduce the exploitability of this issue. Because these are update packets, named must be setup to allow updating of records (which is typical in the case of dynamic DNS), however the RNDC key is required in order to perform the update; possibly if named is configured insecurely to allow hosts on the local network to update without the RNDC key this could be a much larger problem (unverified if that is the case).

By default, both /etc/rndc.conf and /etc/rndc.key are mode 0640 and owned root:named so on the DNS server itself, someone would require named or root privileges to obtain the key; on external systems that may contain the RNDC key for updating, this would depend on that host's security.

It is also required to know a FQDN that already exists on the DNS server; attempting to update a FQDN that does not exist does not cause named to exit. Sample log output for a succesful crash:

Jul 28 11:30:58 hades named[18990]: db.c:579: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
Jul 28 11:30:58 hades named[18990]: exiting (due to assertion failure)

And when the FQDN is not correct:

Jul 28 11:24:36 hades named[8301]: client 10.10.10.10#36034: updating zone 'me.ca/IN': update unsuccessful: 1.me.ca/ANY: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)

And finally, when an incorrect RNDC key is provided:

Jul 28 11:30:16 hades named[18891]: client 10.10.10.10#35404: request has invalid signature: TSIG rndckey: tsig verify failure (BADSIG)

Interestingly, the reproducer is a clever one as it does not exist when named crashes, so if named is restarted or is running under a supervision service to auto-restart, just leaving the reproducer running will continue to cause it to crash indefinitely unless the attacking IP is firewalled off.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538975

A Debian bug report [1] notes that named can be caused to exit with an assertion failure due to a particular update packet.  This will cause a complete exit of named, preventing it from serving any more DNS responses.

The bug includes a reproducer in perl that can be used to trigger this.  I have tried the reproducer against my local network LAN server (running CentOS 5.3) and it works as advertised, however there are a few factors that increase the complexity and reduce the exploitability of this issue.  Because these are update packets, named must be setup to allow updating of records (which is typical in the case of dynamic DNS), however the RNDC key is required in order to perform the update; possibly if named is configured insecurely to allow hosts on the local network to update without the RNDC key this could be a much larger problem (unverified if that is the case).

It is also required to know a FQDN that already exists on the DNS server; attempting to update a FQDN that does not exist does not cause named to exit.  Sample log output for a succesful crash: