CVE-2012-5689: BIND 9 with DNS64 enabled can unexpectedly terminate when resolving domains in RPZ
ISC has learned of the potential for an error condition in BIND 9 that can cause a nameserver to terminate with an assertion failure when processing queries if it has been configured to use both DNS64 and Response Policy Zones (RPZ).
Document version: 2.0
Posting date: 24 January 2013
Program impacted: BIND 9
Versions affected: 9.8.0->9.8.4-P1, 9.9.0->9.9.2-P1
An error condition may occur when a nameserver which is configured to use DNS64 performs a AAAA lookup for a record with an A record rewrite rule in a Response Policy Zone (RPZ). If the RPZ is unable to provide a AAAA record for the name, but does provide a rewritten A record, then the DNS64 processing code will attempt to remap that A record into a AAAA record. Due to a coding error, this interaction between the RPZ database and the DNS64 remapping code can cause the named process to terminate with an assertion failure.
ISC believes the number of deployed systems that are using RPZ rewrite rules and also using DNS64 is extremely small; furthermore, the problem has an easy workaround (see below). However, ISC policy calls for disclosure of any potential vulnerability in BIND 9, regardless of how rarely the conditions for such a vulnerability may occur in production environments. Thus, despite the CVSS score, we assess the severity as Low, and will integrate the bug fix into the next beta release of the affected versions. No security patch release versions are planned, as the workaround is simple and affords complete protection.
To prevent accidental exposure of those using these features in combination, future versions of BIND 9 will include code to prevent any exploitation of this bug, beginning with beta versions scheduled to be released on January 24, 2013. However, the suggested workaround is a complete remedy for those who are using DNS64 in conjunction with RPZ, and is recommended in preference to running beta code in a production environment.
Only nameservers that are configured to use both DNS64 and Response Policy Zones, and which are maintaining A rewrite rules but not AAAA rewrite rules, will be affected by this problem - in other words, only systems that are using RPZ to rewrite DNS records into A records, then attempting to remap those same A records into AAAA via DNS64. Systems that only use RPZ to generate NXDOMAIN or CNAME or NOERROR/NODATA responses, or to rewrite other resource record types besides A, will not trigger the bug.
CVSS Score: 7.8
CVSS Equation: (AV:N/AC:L/Au:N/C:N/I:N/A:C)
For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2&vector=(AV:N/AC:L/Au:N/C:N/I:N/A:C).
If using DNS64 and Response Policy Zones together, make sure the RPZ contains a AAAA rewrite rule for every A rewrite rule. If the RPZ provides a AAAA answer without the assistance of DNS64, the bug is not triggered.
Active exploits: None
Solution: If you are currently running one of the affected versions, you have the following options:
- Employ the workaround (see above).
- Wait for BIND releases that include a fix preventing possible exploitation of the bug.
Acknowledgements: ISC would like to thank Pories Ediansyah of Institut Teknologi Bandung for bringing this defect to our attention.
Document Revision History:
1.0 - Advance Notification to Phase One, 17 January 2013
1.1 - Notification to Phase Two and Phase Three, 23 January 2013
2.0 - Notification to Phase Four, 24 January 2013 (Public)
Japanese Translation: https://kb.isc.org/docs/aa-00857
Spanish Translation: https://kb.isc.org/docs/aa-00859
German Translation: [planned]
Portuguese Translation: https://kb.isc.org/docs/aa-00863
If you'd like more information on ISC Subscription Support and Advance Security Notifications, please visit https://www.isc.org/support/.
See our BIND 9 Security Vulnerability Matrix for a complete listing of security vulnerabilities and versions affected.
Do you still have questions? Questions regarding this advisory should go to email@example.com. To report a new issue, please encrypt your message using firstname.lastname@example.org's PGP key which can be found here: https://www.isc.org/downloads/software-support-policy/openpgp-key/. If you are unable to use encrypted email, you may also report new issues at: https://www.isc.org/community/report-bug/.
Note: ISC patches only currently supported versions. When possible, we indicate EOL versions affected. (For current information on which versions are actively supported, please see https://www.isc.org/downloads/.)
ISC Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found in the ISC Software Defect and Security Vulnerability Disclosure Policy.
This Knowledgebase article is the complete and official security advisory document.
Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.