BIND Dynamic Update DoS
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
bind9 (Debian) |
Fix Released
|
Unknown
|
|||
bind9 (Fedora) |
Fix Released
|
High
|
|||
bind9 (Ubuntu) |
Fix Released
|
High
|
LaMont Jones | ||
Dapper |
Fix Released
|
High
|
Kees Cook | ||
Hardy |
Fix Released
|
High
|
Kees Cook | ||
Intrepid |
Fix Released
|
High
|
Kees Cook | ||
Jaunty |
Fix Released
|
High
|
Kees Cook | ||
Karmic |
Fix Released
|
High
|
LaMont Jones |
Bug Description
Binary package hint: bind9
From https:/
Receipt of a specially-crafted dynamic update message to a zone for which the server is the master may cause BIND 9 servers to exit. Testing indicates that the attack packet has to be formulated against a zone for which that machine is a master. Launching the attack against slave zones does not trigger the assert.
This vulnerability affects all servers that are masters for one or more zones – it is not limited to those that are configured to allow dynamic updates. Access controls will not provide an effective workaround.
dns_db_
Note:
I haven't been affected by this vulnerability yet, but ISC describes it as critical.
$ lsb_release -rd
Description: Ubuntu 9.04
Release: 9.04
$ apt-cache policy bind9
bind9:
Installed: 1:9.5.1.dfsg.P2-1
Candidate: 1:9.5.1.dfsg.P2-1
Version table:
*** 1:9.5.1.dfsg.P2-1 0
500 http://
100 /var/lib/
CVE References
Changed in bind9 (Ubuntu): | |
status: | New → In Progress |
importance: | Undecided → High |
assignee: | nobody → Kees Cook (kees) |
Changed in bind9 (Ubuntu Karmic): | |
assignee: | Kees Cook (kees) → LaMont Jones (lamont) |
Changed in bind9 (Ubuntu Jaunty): | |
assignee: | nobody → Kees Cook (kees) |
importance: | Undecided → High |
status: | New → In Progress |
Changed in bind9 (Ubuntu Intrepid): | |
assignee: | nobody → Kees Cook (kees) |
importance: | Undecided → High |
status: | New → In Progress |
Changed in bind9 (Ubuntu Hardy): | |
assignee: | nobody → Kees Cook (kees) |
importance: | Undecided → High |
status: | New → In Progress |
Changed in bind9 (Ubuntu Dapper): | |
assignee: | nobody → Kees Cook (kees) |
importance: | Undecided → High |
status: | New → In Progress |
visibility: | private → public |
Changed in bind9 (Debian): | |
status: | Unknown → New |
Changed in bind9 (Fedora): | |
status: | Unknown → Confirmed |
Changed in bind9 (Fedora): | |
status: | Confirmed → Fix Released |
Changed in bind9 (Debian): | |
importance: | Undecided → Unknown |
status: | Fix Released → Unknown |
Changed in bind9 (Debian): | |
status: | Unknown → Fix Released |
Changed in bind9 (Fedora): | |
importance: | Unknown → High |
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