DNS protocols were designed with the assumption that a certain amount of trust could be presumed between the operators of primary and secondary servers for a given zone. However, in current practice some organizations have scenarios which require them to accept zone data from sources that are not fully trusted (for example: providers of secondary name service). A party who is allowed to feed data into a zone (e.g. by AXFR, IXFR, or Dynamic DNS updates) can overwhelm the server which is accepting data by intentionally or accidentally exhausting that server's memory.
Posting date: 07 July 2016
9.0.x -> 9.9.9-P2, 9.10.0 -> 9.10.4-P2, 9.11.0a1 -> 9.11.0b2
A server is potentially vulnerable if it accepts zone data from another source, as no limit is currently placed on zone data size. A master server can therefore feed excessive data to a slave server, exhausting its memory. Similarly a client allowed to insert records into a zone using dynamic updates can also cause a zone to grow without limit until memory is exhausted. In all cases a trust relationship allowing the attacker to insert zone data must exist between the two parties for an attack to occur using this vector.
A server which is successfully attacked using this method can have its memory exhausted, causing unpredictable behavior or termination by the OS when it runs out of memory.
In a typical case where zone data is accepted only from trusted sources under the control of the same organization, servers are at little risk. The chief risk from this attack vector is to parties who operate secondary name servers which accept zone data from not fully trusted sources.
Operators of servers which accept untrusted zone data can mitigate their risk by operating an intermediary server whose role it is to receive zone data and then (if successful) re-distribute it to client-facing servers. Successful exploitation of the attack against the intermediary server may still occur but denial of service against the client-facing servers is significantly more difficult to achieve in this scenario.
No known active exploits, but a public discussion of the issue has taken place on a public mailing list and a CVE assignment has been requested by a party other than ISC.
In practice this vulnerability has existed for as long as slave servers have taken data from master servers and has no history (of which we are aware) of being exploited as an attack vector because it requires an existing trust relationship as a prerequisite and identification of the attacking party is very easy (at which point the trust relationship can be revoked).
However, it is a possible attack vector and recent public discussion and a CVE assignment requested by an outside party have prompted us to issue a statement on the subject in this Operational Notification.
ISC wish to stress that the behavior in question is not a failure of BIND to implement DNS protocols correctly, but is if anything an oversight in the protocol. However, for the convenience of operators who take zone data from untrusted sources (such as secondary name service providers) we have committed to delivering a feature in upcoming maintenance releases of BIND which will address the issue by allowing operators to set limits on the maximum zone size BIND will accept.
Document Revision History:
1.0 Public Disclosure, 07 July 2016
1.1 Updated Versions affected to include 9.9.9-P2, 9.10.4-P2, and 9.11.0-b2
Do you still have questions? Questions regarding this advisory should go to email@example.com
ISC Disclosure Policies: Additional information on our Operational Notifications can be found at: https://www.isc.org/software/notifications, and Phased Disclosure Process at: https://www.isc.org/security-vulnerability-disclosure-policy
This Knowledge Base article https://kb.isc.org/editArticle/AA-01390 is the complete and official operational notification document.
Legal Disclaimer: 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.
© 2001-2017 Internet Systems ConsortiumFor 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.