Hash: SHA256

             AUSCERT External Security Bulletin Redistribution

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


        AusCERT Security Bulletin Summary

Product:           BIND
Publisher:         ISC
Operating System:  Windows
                   UNIX variants (UNIX, Linux, OSX)
Impact/Access:     Denial of Service -- Existing Account
Resolution:        Patch/Upgrade
CVE Names:         CVE-2016-6170  

Original Bulletin: 

- --------------------------BEGIN INCLUDED TEXT--------------------

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

Author: Michael McNally 

Reference Number: AA-01390 

Views: 8490 

Created: 2016-07-07 20:44 

Last Updated: 2016-07-18 23:47


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.



Document Version:


Posting date:

07 July 2016

Program Impacted:


Versions affected:

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.

Active exploits:

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 

ISC Disclosure Policies: Additional information on our Operational 
Notifications can be found at: https://www.isc.org/software/notifications, and
Phased Disclosure Process at: 

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-2016 Internet Systems Consortium

Please help us to improve the content of our knowledge base by letting us know
below how we can improve this article.

If you have a technical question or problem on which you'd like help, please 
don't submit it here as article feedback.

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.

- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:


Australian Computer Emergency Response Team
The University of Queensland
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
Comment: http://www.auscert.org.au/render.html?it=1967