CVE-2011-4313 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?

• Authoritative-only servers are not vulnerable.   Only servers acting in a recursive / resolving capacity are affected.
• Recursive servers are vulnerable if they query zones which you do not directly control (for example, if they query zones on the internet.)
• Resolving queries through a forwarder does not prevent exposure to this vulnerability.
• 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.

Analysis and Mitigation

What Happened?

Having completed our analysis of the data submitted by those who experienced the crash, ISC has identified how and why this event occurred.

We have confirmed that it was triggered by an accidental operational error that exposed a previously unknown bug in BIND, causing an internal inconsistency which is effectively prevented by the mitigation patches we have produced and distributed.

While the original trigger for this incident no longer exists, it is very possible that the same set of circumstances could be made to recur deliberately rather than accidentally. Therefore, ISC strongly recommends that those running vulnerable servers continue to update to a patched release of BIND.

ISC is sensitive to the fact that emergency upgrades are operationally disruptive.  The released patched versions address the immediate cause of this crash but include no other changes from the base versions from which they were derived.

Having completed our analysis of the cause we believe that we understand the mechanism that caused the failure and have corrected it, but in the event that other methods to trigger this defect are found, we will release another patch.  If no other triggers are discovered, ISC intends to include a more comprehensive and permanent fix in a point release, rather than a security release.

##### A Mitigation Strategy For Those Who Cannot Upgrade Immediately

For customers who are unable to migrate immediately to a patched version of BIND, there is now a mitigation strategy available.  ISC continues to strongly recommend installing a patched version as the safest course of action, but if circumstances prevent you from doing so you can still reduce or eliminate your exposure to the CVE-2011-4313 vulnerability with a configuration option addition to named.conf.

DNS messages are divided into sections (Query, Answer, Authority, and Additional) containing different elements.  ISC's analysis of the events of 16 November 2011 indicate that nameservers that were compromised crashed after caching information in the Additional section inappropriately.

If you are operating a recursing-only nameserver, configuring your server with this configuration option: [1]

minimal-responses yes;

suppresses the inclusion of data in the Authority and Additional sections of a response when that data is not required by RFC, thereby avoiding the code path that contains the INSIST.Note: we have also tested patching your forwarder if it's between your internal recursing server and your clients

In "mixed-mode" servers which perform both authoritative and recursing functions, "minimal-reponses yes;" reduces but does not eliminate your exposure.  Your best options in this case are to deploy a patched version as soon as possible or to separate the recursing and authoritative functions of your nameservers.

Authoritative-only servers are not at risk from CVE-2011-4313.

[1] The minimal-responses configuration option was introduced in BIND 9.2 and is not available in BIND 9.0 or 9.1.  Please upgrade.

A Possible Consideration Concerning the Mitigation Strategy

The mitigation strategy described above works by invoking an option in BIND which suppresses data in the Authority and Additional sections of a response when that data is not required by the RFCs defining the protocol.  Without setting "minimal-responses yes;" in named.conf, BIND's default behavior is to provide extra information not required by protocol in those sections of some query responses.

While we are not specifically aware of any, it is possible that programs written by other organizations may be written to expect the extra information BIND has provided by default, even though that information is not required by the RFC.  Using the "minimal-reponses yes;" mitigation strategy could hypothetically cause changes in the behavior of such programs.  The fallback position in the event that you encounter difficulties using "minimal-responses yes;" is to upgrade to a patched version of BIND.

© 2001-2018 Internet Systems Consortium
For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.