BIND Dynamic Update DoS

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

CERT has their vulnerability note here: http://www.kb.cert.org/vuls/id/725188

Created attachment 355461
difference between 9.4.3-P2 and 9.4.3-P3 to correct this issue

Upstream releases are also available:

http://oldwww.isc.org/sw/bind/view?release=9.4.3-P3&noframes=1
http://oldwww.isc.org/sw/bind/view?release=9.5.1-P3&noframes=1
http://oldwww.isc.org/sw/bind/view?release=9.6.1-P1&noframes=1

ISC's advisory on this issue: https://www.isc.org/node/474 :

Description:

Urgent: this exploit is public. Please upgrade immediately.

Receipt of a specially-crafted dynamic update message may cause BIND 9 servers to exit. This vulnerability affects all servers – it is not limited to those that are configured to allow dynamic updates. Access controls will not provide an effective workaround.

dns_db_findrdataset() fails when the prerequisite section of the dynamic update message contains a record of type “ANY” and where at least one RRset for this FQDN exists on the server.

db.c:659: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
exiting (due to assertion failure).
Workarounds:
None.

(Some sites may have firewalls that can be configured with packet filtering techniques to prevent nsupdate messages from reaching their nameservers.)
Active exploits:
An active remote exploit is in wide circulation at this time.

Based on the original advisory, this appears to affect only "master" servers. One standard best practice is to have one master and multiple slaves and to protect that master (no exposure to the Internet). This would seem to be a mitigation. This is a BCP (Best Common Practice) for those of us who have been doing this for years.

Sites with authoritative name servers definitely should upgrade AND fix their configurations to protect their masteres.

I've reproduced this bug with the stock RHEL4 bind (bind-9.2.4-30.el4_7.2).

I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a source
package and binary packages that fix it (under the same conditions, the patched
named no longer aborts), and placed it all (patch, spec file, source RPM, and binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind

The direct URL for the patch is http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch;
please feel free to use it as appropriate.

Best Regards,
--
   Durval Menezes <durval AT tmp DOT com DOT br>

bind-9.6.1-4.P1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/bind-9.6.1-4.P1.fc11

bind-9.5.1-3.P3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/bind-9.5.1-3.P3.fc10

(In reply to comment #11)
> I've reproduced this bug with the stock RHEL4 bind (bind-9.2.4-30.el4_7.2).
>
> I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a
> source
> package and binary packages that fix it (under the same conditions, the patched
> named no longer aborts), and placed it all (patch, spec file, source RPM, and
> binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind
>
> The direct URL for the patch is
> http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch;
> please feel free to use it as appropriate.
>
> Best Regards,
> --
> Durval Menezes <durval AT tmp DOT com DOT br>

Solaris Designer reproduce the bug also without using dynamic update

quote

On Wed, Jul 29, 2009 at 05:15:09PM +0400, Solar Designer wrote:
> Confirmed on 9.3.5-P2 (removing the "$packet->sign_tsig(...)" line from
> the exploit as above) with whatever patches we happened to have until
> this latest fix.

It gets worse: I was also able to crash named from an IP address
explicitly denied in "allow-query". I did verify that non-malicious
queries from that IP address were indeed correctly denied.

It appears that BIND does too much processing too early in the code.

Alexander

quote

Found on oss-security mailing list

(In reply to comment #11)
> The direct URL for the patch is
> http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch;
> please feel free to use it as appropriate.

Updates with similar patch are undergoing quality assurance testing now and will be released as soon as they are fully tested.

(In reply to comment #14)
> Solaris Designer reproduce the bug also without using dynamic update

ISC have already acknowledged that the bug affects instances where the configuration does not permit updates. It is not updates themselves that cause the problem, but packets masquerading as updates - whether they would work or not.

There is some workarrond for this?

Regards.

Priscila Veiga

https://www.isc.org/node/474

Upon further investigation it was found that that crash is not limited to configurations that allow updates, contrary to what was originally reported. As well, the allow-query keyword does not prove an effective ACL mechanism to protect the server, as IPs that are explicitly denied by allow-query can still trigger a crash.

(In reply to comment #18)
> There is some workarrond for this?

The only work-around for this issue seems to be firewall-based rules to prevent unauthorized systems from talking at all to the named service. Also see comment #8 regarding master and slave servers.

*** Bug 514481 has been marked as a duplicate of this bug. ***

Source RPMs of fixed packages which are undergoing quality assurance testing are also available on http://people.redhat.com/atkac/bind/. Note those packages are _NOT_ official release.

(In reply to comment #11)
>
> I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a
> source
> package and binary packages that fix it (under the same conditions, the patched
> named no longer aborts), and placed it all (patch, spec file, source RPM, and
> binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind
>
> The direct URL for the patch is
> http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch;
> please feel free to use it as appropriate.
>
> Best Regards,
> --
> Durval Menezes <durval AT tmp DOT com DOT br>

You seem to be missing bind-chroot at that location.

Is there a possibility to back-port it to redhat 7.3?

(In reply to comment #28)
> (In reply to comment #11)
> >
> > I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a
> > source
> > package and binary packages that fix it (under the same conditions, the patched
> > named no longer aborts), and placed it all (patch, spec file, source RPM, and
> > binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind
> >
> > The direct URL for the patch is
> > http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch;
> > please feel free to use it as appropriate.
> >
> > Best Regards,
> > --
> > Durval Menezes <durval AT tmp DOT com DOT br>
>
> You seem to be missing bind-chroot at that location.

Indeed. bind-chroot had strange issues at my installation, and since it's just a chroot-tree (which most/all people running bind in a chrooted configuration will already have), I just removed it initially. Will check it later and post it too.
Anyway, if you need the bind-chroot, feel free to recompile it from my src.rpm.

(In reply to comment #33)
> (In reply to comment #28)
> > (In reply to comment #11)
> > >
> > > I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a
> > > source
> > > package and binary packages that fix it (under the same conditions, the patched
> > > named no longer aborts), and placed it all (patch, spec file, source RPM, and
> > > binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind
> > >
> > > The direct URL for the patch is
> > > http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch;
> > > please feel free to use it as appropriate.
> > >
> > > Best Regards,
> > > --
> > > Durval Menezes <durval AT tmp DOT com DOT br>
> >
> > You seem to be missing bind-chroot at that location.
>
> Indeed. bind-chroot had strange issues at my installation, and since it's just
> a chroot-tree (which most/all people running bind in a chrooted configuration
> will already have), I just removed it initially. Will check it later and post
> it too.
> Anyway, if you need the bind-chroot, feel free to recompile it from my src.rpm.

Done that and everything went well, thank you.

(In reply to comment #31)
> Is there a possibility to back-port it to redhat 7.3?

Dmitri, Red Hat Linux 7.3 is not supported for years, so there will be no update for it. The patch for later bind version (e.g. from RHEL3) may apply cleanly to bind in 7.3, but you'll have to do you own backport / build.

> 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.

Maybe I'm misunderstanding...could someone please clarify? Wouldn't this imply that as long as the box is secure that no malicious attacker could send a packet since they wouldn't have the correct permissions to access the RNDC key?

(In reply to comment #11)
> http://www.durval.com.br/RPMS/el4/bind

A note to all using Durval's packages. If you install them, you may not get official updates installed automatically due to Durval's packages having newer NVR and you may need to install them manually.

(In reply to comment #35)
> (In reply to comment #31)
> > Is there a possibility to back-port it to redhat 7.3?
>
> Dmitri, Red Hat Linux 7.3 is not supported for years, so there will be no
> update for it. The patch for later bind version (e.g. from RHEL3) may apply
> cleanly to bind in 7.3, but you'll have to do you own backport / build.

Thanks for the heads up.

Here's what happens when I try to build rpm from srcrpm taken from
http://people.redhat.com/atkac/bind/bind-9.2.4-25.el3.src.rpm
glibc-headers-2.3.2-101.4
gcc-2.96-112.7.2

gcc -O2 -g -march=i386 -mcpu=i686 -g -I/usr/src/redhat/BUILD/bind-9.2.4
-I./include -I./../pthreads/include -I../include -I./../include -I./..
-D_REENTRANT -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat
-c interfaceiter.c -fPIC -DPIC -o .libs/interfaceiter.lo
In file included from include/isc/net.h:88,
                 from interfaceiter.c:36:
../include/isc/ipv6.h:63: redefinition of `struct in6_addr'
../include/isc/ipv6.h:81: redefinition of `struct sockaddr_in6'
In file included from interfaceiter.c:36:
include/isc/net.h:159: redefinition of `struct in6_pktinfo'
include/isc/net.h:202: warning: redefinition of `in_port_t'
/usr/include/netinet/in.h:92: warning: `in_port_t' previously declared here
make[3]: *** [interfaceiter.lo] Error 1
make[3]: Leaving directory `/usr/src/redhat/BUILD/bind-9.2.4/lib/isc/unix'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/bind-9.2.4/lib/isc'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/bind-9.2.4/lib'
make: *** [subdirs] Error 1

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2009:1179 https://rhn.redhat.com/errata/RHSA-2009-1179.html

This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2009:1180 https://rhn.redhat.com/errata/RHSA-2009-1180.html

This issue has been addressed in following products:

  Red Hat Enterprise Linux 3

Via RHSA-2009:1181 https://rhn.redhat.com/errata/RHSA-2009-1181.html

We will be repushing the RHEL5 update shortly: The packages in this erratum have been updated to also correct this issue in the bind-sdb package.

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2009:1179 https://rhn.redhat.com/errata/RHSA-2009-1179.html

(In reply to comment #42)
> This issue has been addressed in following products:
> Red Hat Enterprise Linux 4
> Via RHSA-2009:1180 https://rhn.redhat.com/errata/RHSA-2009-1180.html

There are still no new rpms in http://mirror.centos.org/centos/4/updates/i386/RPMS/ when 3.x and 5.x have new bind rpms

bind-9.6.1-4.P1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.

bind-9.5.1-3.P3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.

When you will put RPMs for Red Hat Enterprise Linux 4? There are still old RPMS on http://mirror.centos.org/centos/4/updates/i386/RPMS/

FWIW, the Debian report mentions use of the u32 iptables module to suppress packets based upon matching a bit-string, as in:

iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5'

Unfortunately, the u32 module doesn't seem to exist in RHEL kernels ( and hence also CentOS ). The 32 module is mentioned in the manual, even though it doesn't exist in the kernel, BTW.

After some experimentation, I've found that a partial workround is to use the string module instead searching for a single hex-byte:

iptables -I INPUT -p udp --dport 53 -m string --algo kmp --from 30 --to 31 --hex-string '|28|' -j LOG --log-prefix "warning: DROPDNS: " --log-level warning

Note that this string search matches on 8-bits, whereas u32 matches on 4. RFC2136 requires 3 of the other bits to be sent as zero, but ignored if non-zero. Hence there's no guarantee that an attacker might not be able to use hex-strings 29 through 2F instead, which would need 7 more iptables rules. There may be a way of expressing this via a regex, but the iptables manual is very thin on details in this regard.

I also assume that string matching on every DNS packet in the kernel is probably CPU hungry, but this workround may at least provide enough medicine to keep the patient alive until the RPM update ambulance arrives.

(In reply to comment #50)
> FWIW, the Debian report mentions use of the u32 iptables module to suppress
> packets based upon matching a bit-string, as in:
>
> iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5'
>
> Unfortunately, the u32 module doesn't seem to exist in RHEL kernels ( and hence
> also CentOS ). The 32 module is mentioned in the manual, even though it doesn't
> exist in the kernel, BTW.
>
> After some experimentation, I've found that a partial workround is to use the
> string module instead searching for a single hex-byte:
>
> iptables -I INPUT -p udp --dport 53 -m string --algo kmp --from 30 --to 31
> --hex-string '|28|' -j LOG --log-prefix "warning: DROPDNS: " --log-level
> warning
>
> Note that this string search matches on 8-bits, whereas u32 matches on 4.
> RFC2136 requires 3 of the other bits to be sent as zero, but ignored if
> non-zero. Hence there's no guarantee that an attacker might not be able to use
> hex-strings 29 through 2F instead, which would need 7 more iptables rules.
> There may be a way of expressing this via a regex, but the iptables manual is
> very thin on details in this regard.
>
> I also assume that string matching on every DNS packet in the kernel is
> probably CPU hungry, but this workround may at least provide enough medicine to
> keep the patient alive until the RPM update ambulance arrives.

This is protection against UDP based queries only. TCP based queries will still knock down your named.

(In reply to comment #37)
> Maybe I'm misunderstanding...could someone please clarify? Wouldn't this imply
> that as long as the box is secure that no malicious attacker could send a
> packet since they wouldn't have the correct permissions to access the RNDC
> key?

Comment #20 has update for the initial description. Further investigation proved that the broken code is reachable even with update request packet that is not signed (hence attacked does not need to know key configured on the server) and even if bind is not configured for dynamic updates.

(In reply to comment #39)
> Here's what happens when I try to build rpm from srcrpm taken from
> http://people.redhat.com/atkac/bind/bind-9.2.4-25.el3.src.rpm

My though was more about taking SRPM from 7.3 and adding patch extracted from RHEL3 SRPM to it. Though there may be other unfixed security flaws form the past as well.

(In reply to comment #49)
> When you will put RPMs for Red Hat Enterprise Linux 4? There are still old RPMS
> on http://mirror.centos.org/centos/4/updates/i386/RPMS/

Red Hat Enterprise Linux 4 updates are available via Red Hat Network, SRPM are also available on FTP:

ftp://updates.redhat.com/enterprise/4AS/en/os/SRPMS/

Only CentOS team can tell when corresponding CentOS updates for CentOS 4 will be available. You can watch centos-announce list for updates:

http://lists.centos.org/mailman/listinfo/centos-announce

(In reply to comment #53)
> (In reply to comment #39)

> My though was more about taking SRPM from 7.3 and adding patch extracted from
> RHEL3 SRPM to it. Though there may be other unfixed security flaws form the
> past as well.

I was able to successfully patch bind-9.2.1-1.7x.2.src.rpm using contents of bind-9.2.4-CVE-2009-0696.diff from bind-9.2.4-25.el3.src.rpm

Resulting package seems stable and fixes this particular flaw.

(In reply to comment #54)
> (In reply to comment #49)
> > When you will put RPMs for Red Hat Enterprise Linux 4? There are still old RPMS
> > on http://mirror.centos.org/centos/4/updates/i386/RPMS/
>
> Red Hat Enterprise Linux 4 updates are available via Red Hat Network, SRPM are
> also available on FTP:
>
> ftp://updates.redhat.com/enterprise/4AS/en/os/SRPMS/
>
> Only CentOS team can tell when corresponding CentOS updates for CentOS 4 will
> be available. You can watch centos-announce list for updates:
>
> http://lists.centos.org/mailman/listinfo/centos-announce

since it updated, BIND stop responding to requests IPv6 regularly. we have found these errors:
Sep 1 04:02:01 tree named[8364]: client.c:1334: unexpected error:
Sep 1 04:02:06 tree named[8364]: client.c:1334: unexpected error:
Sep 1 04:02:11 tree named[8364]: client.c:1334: unexpected error:

At 04:02 AM logrotate execute '/sbin/service named reload 2> /dev/null > /dev/null || true'

it seems that there is a link between the reload and the probleme

Regards,

(In reply to comment #57)
> since it updated, BIND stop responding to requests IPv6 regularly. we have
> found these errors:
> Sep 1 04:02:01 tree named[8364]: client.c:1334: unexpected error:
> Sep 1 04:02:06 tree named[8364]: client.c:1334: unexpected error:
> Sep 1 04:02:11 tree named[8364]: client.c:1334: unexpected error:

It seems you are affected by bug #518866.