CVE-2012-5166 FAQ and Supplemental Information
- Updated on 17 Oct 2012
- 2 minutes to read
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?
The problem is encountered when a server is assembling a query response from resource records found either in cache or from authoritative zone data loaded into memory. A specific combination of records will cause named to lock up. These records may not necessarily all reside in the same zone.
- Authoritative servers whose trusted administrators control their zone data should not be vulnerable, although it's possible (but very unlikely) that this could be encountered accidentally.
- Authoritative servers who permit dynamic zone data updates directly from clients could be impacted by malicious updates. If your servers permit dynamic updates, you should only allow these from trusted clients and should also limit the scope of updates permitted via configuration options allow-update or update-policy . The update-policy option provides significantly improved granularity of control versus allow-update .
- Slave servers receiving unsecured zone updates could be vulnerable to zone data poisoning via impersonation.
- Recursive servers whose clients can make queries for names in the Internet name space (as opposed to being restricted to internal organizational Intranets) are vulnerable to attackers who have set up authoritative servers that provide records in combinations that when assembled in a client response by recursive server will encounter this problem. (Note that there are many techniques available to induce non-malicious clients to make DNS recursive queries that are intended to cause harm).
Are there any reliable mitigations?
- Setting "minimal-responses yes; " will prevent the problem on both Authoritative and Recursive servers.
- On an Authoritative nameserver, setting "additional-from-auth no; " and "additional-from-cache no; " are not sufficient to prevent this problem in all cases.
Is the Response Rate Limiting code included in these new patched versions of BIND?
No - Response Rate Limiting is an experimental feature which ISC has not yet incorporated into mainlineBIND. The RRL code patches are maintained, updated and available fromhttp://www.redbarn.org/dns/ratelimits. There is no relationship between the current security issue and response rate limiting.
© 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.