Security & Vulnerability Updates

BIND 9 DNSSEC validation code could cause bogus NXDOMAIN responses

A vulnerability has been announced by the US-CERT (US Computer Emergency Readiness Team) – http://www.kb.cert.org/vuls/id/360341 - which affects the version of BIND running in versions 6.x of Adonis.
 
US-CERT provides the following description:

The Berkeley Internet Name Domain (BIND) is a popular Domain Name System (DNS) implementation from Internet Systems Consortium (http://www.isc.org/) (ISC). There was an error in the DNSSEC NSEC/NSEC3 validation code that could cause bogus NXDOMAIN responses (that is, NXDOMAIN responses for records proven by NSEC or NSEC3 to exist) to be cached as if they had validated correctly, so that future queries to the resolver would return the bogus NXDOMAIN with the AD flag set.

Adonis systems running versions 6.x are vulnerable.

BlueCat has released a patch which addresses this vulnerability (US CERT VU #360341), that patches Adonis 6.x systems to ISC BIND version 9.6.1-P3, which mitigates this vulnerability. This patch can be acquired by contacting BlueCat Networks via the Customer Care Portal.

BIND 9 Cache Update from Additional Section – US CERT VU# 418861 (Updated January 19, 2010)

A vulnerability has been announced by the US-CERT (US Computer Emergency Readiness Team) – http://www.kb.cert.org/vuls/id/418861 - which affects the version of BIND running in versions 6.x of Adonis.
 
US-CERT provides the following description:

A nameserver with DNSSEC validation enabled may incorrectly add unauthenticated records to its cache that are received during the resolution of a recursive client query with checking disabled (CD), or when the nameserver internally triggers a query for missing records for recursive name resolution. Cached records can be returned in response to subsequent client queries with or without requesting DNSSEC records (DO). In addition, some of them can be returned to queries with or without checking disabled (CD).

*Severity: Medium (SEVERE for nameservers with DNSSEC validation enabled)

Previously a patch had been release, updating vulnerable Adonis 6.x versions to ISC BIND 9.6.1-P2. However, those fixes were found to be incomplete by ISC, and as such have released BIND version 9.6.1-P3

Adonis systems running versions 6.x are vulnerable.

BlueCat has released a patch which addresses this vulnerability (US CERT VU #418861), that patches Adonis 6.x systems to ISC BIND version 9.6.1-P3, which mitigates this vulnerability. This patch can be acquired by contacting BlueCat Networks via the Customer Care Portal.

BIND 9 Cache Update From Additional Section

The ISC (Internet Systems Consortium), developers of the BIND DNS server, has announced a vulnerability which affects the version of BIND running in versions 6.x of Adonis.

This is a potential security risk that only affects customers that allow recursive DNS queries and are performing DNSSEC validation. 

BlueCat has a patch available for Adonis that will upgrade the underlying instance of ISC BIND to the relevant patched version of the software, now released by ISC, to mitigate this issue. This patch addresses the vulnerability by incorporating the ISC BIND patch which addresses CERT VU#418861.

For Adonis versions 6.x, click the link below to access the patch and installation instructions.

ftp://adonis:Ad0n1s!@supportftp.bluecatnetworks.com/patch112409

A vulnerability has been announced by the US-CERT (US Computer Emergency Readiness Team) – http://www.kb.cert.org/vuls/id/725188 - which affects the version of BIND running in versions 4.x, 5.x, and 6.x of Adonis.

US-CERT provides the following description:

The Berkeley Internet Name Domain (BIND) is a popular Domain Name System (DNS) implementation from Internet Systems Consortium (http://www.isc.org/) (ISC). It includes support for dynamic DNS updates as specified in IETF RFC 2136 (http://tools.ietf.org/html/rfc2136) . BIND 9 can crash when processing a specially-crafted dynamic update packet. ISC notes that this vulnerability affects all servers and is not limited to those that are configured to allow dynamic updates.

BlueCat is working diligently to release an update to Adonis that will upgrade the underlying the instance of ISC BIND to the relevant patched version of the software, now released by ISC, which will mitigate this issue. An announcement will be made as soon as this is available.

Note: If you have xHA (Crossover High Availability) enabled, the cluster will failover if attacked. This should somewhat prevent service interruption until a patch is made available.

Once receiving this announcement customers are strongly encouraged to patch their severs immediately, as there is no viable workaround for this issue.

On January 18, 2009, the SANS Internet Storm Center reported the first instances of what is now being described as a DNS DDOS (distributed denial of service) attack (see http://isc.sans.org/diary.html?storyid=5713).

The attack is simple: the attacker spoofs the victim’s source address in a DNS query for ‘.’ (dot) to a DNS server, which then generates a much larger response to be sent to the victim. This is also known as an amplification attack whereby the attacker’s traffic is amplified 10-fold by the natural DNS response. The purpose of the attack is to generate as much traffic as possible to victim’s system (the spoofed address used) or network.

It is also quite likely that the owner or administrators of the participating DNS server are completely unaware that their system is being used in this way. In fact, if the queries are successfully answered, then most logging levels will not report this activity at all.

The attack takes advantage of certain configurations on the part of the participating DNS server. This includes all BIND and Microsoft DNS servers.

For Adonis, the results are as follows:

v5.5.0 and v5.5.1

With recursion enabled:

Check that “allow-query-cache” is not set to allow more than “allow-recursion”. If they do not conflict, then the server will deny the request and defeat the attack.

With recursion not enabled:

Set additional-from-cache no; the server will deny the request and defeat the attack.

v5.1

With recursion enabled:

The system will respond to these requests regardless of any other settings. We recommend disabling recursion on external facing Adonis systems.

With recursion disabled:

Set additional-from-cache no, set additional-from-auth no; the server will deny the request and defeat the attack.

You can also see various other mechanisms to detect and protect against this attack on the SAN site (see http://isc.sans.org/diary.html?storyid=5713).

Neither ISC nor CERT have issued any advisories, vulnerability or other notices, indicating that this is not considered a major problem. Reports on the incidence of attacks have been low in number.

If you have special concerns, please contact BlueCat support at This e-mail address is being protected from spambots. You need JavaScript enabled to view it .

A vulnerability has been announced by the US-CERT (US Computer Emergency Readiness Team) — http://www.kb.cert.org/vuls/id/800113 — which affects the version of BIND running in versions 4.x and 5.x of Adonis.

US-CERT provides the following description:

"Deficiencies in the DNS protocol and common DNS implementations facilitate DNS cache poisoning attacks. […] The following are examples of these deficiencies and defects:

• Insufficient transaction ID space
• Multiple outstanding requests
• Fixed source port for generating queries"

BlueCat has released updates to Adonis v4 and v5 that will upgrade the underlying the instance of BIND DNS server to the latest release of the software, now released by ISC, which will mitigate this issue. Customers can obtain more information on how to download and apply the patch in the self-service portal or by contacting support.

To further mitigate the risk associated with this issue, customers are encouraged to do one, or all, of the following:

1. Disable recursion

Disable recursion by way of Access Control Lists to only allow trusted systems to perform recursive queries. If recursion is unnecessary it should be turned off until systems can be patched.

2. Restrict access

Administrators, particularly those who are unable to apply a patch, can limit exposure to this vulnerability by restricting sources that can ask for recursion. Note that restricting access will still allow attackers with access to authorized hosts to exploit this vulnerability.

3. Filter traffic at network perimeters

Because the ability to spoof IP addresses is necessary to conduct these attacks, administrators should filter spoofed addresses at the network perimeter. IETF Request for Comments (RFC) documents RFC 2827, RFC 3704, and RFC 3013 describe best current practices (BCPs) for implementing this defense. It is important to understand your network's configuration and service requirements before deciding what changes are appropriate.

For information on this US CERT Vulnerability, please refer to http://www.kb.cert.org/vuls/id/800113.

To obtain more information to correct this BIND vulnerability, please logon to the BlueCat support portal or contact This e-mail address is being protected from spambots. You need JavaScript enabled to view it .