Operational Notification: A party that is allowed control over zone data can overwhelm a server by transferring huge quantities of data.
  • 29 Oct 2018
  • 4 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Operational Notification: A party that is allowed control over zone data can overwhelm a server by transferring huge quantities of data.

  • Dark
    Light
  • PDF

Article Summary

Summary

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.

CVECVE-2016-6170

Document Version: 1.1

Posting date: 07 July 2016

Program ImpactedBIND

Versions affected: 9.0.x -> 9.9.9-P2, 9.10.0 -> 9.10.4-P2, 9.11.0a1 -> 9.11.0b2

Description

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.

Impact:

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.

Workarounds:

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.

Active exploits:

There are 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.

Solution

ISC wishes 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 security-officer@isc.orgTo report a new issue, please encrypt your message using security-officer@isc.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 here: ISC Software Defect and Security Vulnerability Disclosure Policy.

This Knowledgebase article is the complete and official security advisory 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.