CVE-2012-1667 FAQ and Supplemental Information

About This Document

For up-to-date information on this vulnerability, patches, and other operational information, please see the official vulnerability announcement. This article is intended to supplement the information in that announcement and will be updated as needed to further describe the operational impact of this vulnerability.

Am I vulnerable?

• Recursive servers are vulnerable if they query zones which you do not directly control (for example, if they query zones on the Internet.)
• You are potentially vulnerable if you resolve queries for data provided by a third party. Examples could include addresses in email, html links in web pages, or queries submitted by users.
• Resolving queries through a forwarder does not prevent exposure to this vulnerability.
• Authoritative servers may be vulnerable if they receive and serve zone data that is maintained by third parties - this includes records created by dynamic updates or provided via zone transfer.

How was this vulnerability discovered and why hasn't it been seen before now?

The problem was uncovered by researchers experimenting with new DNS record types. Since they're undefined by the DNS protocol, BIND does not have any built-in validation of the RRsets when loading the zones. These recent experiments with undefined DNS record types exposed the problem for the first time.

What are experimental record types?

These are record types that are (currently) unknown. The type field has values that are documented in the DNS Protocol RFCs, including many newer types.

Are these packets that cause the problem malformed?

No - they are not malformed - they're constructed correctly per DNS protocol.

Can I accidentally create and load zone data with records that cause my authoritative server to have problems?

This is extremely unlikely because BIND validates zone files before loading them. You should not be able to create and load records that expose the problem using well-known DNS record types.

What does 'disclose some portion of memory to the client' mean?

Under this defect, if a server holds this type of record, the internal data structures can be processed incorrectly with the result that a client query response might sometimes include information from portions of memory that were not part of that resource record.

Can I protect my servers using firewalls or packet filtering techniques?

It might be possible to filter on inbound DNS protocol traffic (for example on query responses, dynamic updates and zone transfers) but this would require deep inspection of the individual Resource Records within the packets. Most filtering tools and firewalls have insufficient granularity of control. This type of approach also creates a potential traffic bottleneck. Upgrading BIND is the recommended solution.

It is also not recommended to deploy filtering to limit inbound traffic to packets containing known DNS record types because such filters may in the future prevent the correct operation of new protocols or applications.

Are earlier versions of BIND vulnerable?

We have not tested (and do not intend to test) BIND8 and BIND4 for this vulnerability since they are EOL (End of Life), vulnerable to other security weaknesses already, and their use is not recommended. However, our knowledge of the internals of the BIND8 and BIND4 products leads us to believe that they would both be vulnerable to CVE-2012-1667.