Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2016.2084
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:
https://kb.isc.org/article/AA-01390/169/CVE-2016-6170
- --------------------------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
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.
CVE:
CVE-2016-6170
Document Version:
1.1
Posting date:
07 July 2016
Program Impacted:
BIND
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:
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 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
security-officer@isc.org
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-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:
http://www.auscert.org.au/render.html?cid=1980
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
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.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQIVAwUBV8kTW4x+lLeg9Ub1AQghMg/8C62Ds5lTRVHuyzwsvfBIVt65R/bdOTzf
tdEqvutcQ8wNwoef1Hd/AgphqY3SVKISdHM6EugbSIr/cSalK0wDJHHRZadqqkaF
E5McyawYRbbvuT4iniuVO11jxYoOualKXuxwLch2aN9ogUKwEPciR2ZD9pRrlnFT
caczAOypdA8mq8f12jzOaNrAwFML/VIFeXGrMkuDgva3XoDOV1AyKXt2frzI9RTg
2cGR4URfZcoEqqF9kfsgABZq90H1CilWUK6jtchX3pQw5ILVfzv5Hhk9os+S6Iqk
0bmCf+Syuqb1XmjnuWptHcPYgFrtP45Y2Z0lTpIUDDH8Ht99X5QfQ5/gPJlaqWCq
mhhZVeTrupbFqB+1XF3bwglTp3W33dbf8Vo1fclXa9tQtVT7DvIE3uTvfdfsLwxh
2r1q8C35uVzc+E3ijLU/kBwWEAcEGWRiVUQoBcAAx6QY/lJ04JuTiAqX+1B2j5Ml
S7+LlaB75Zzp2+7cmNFEg/ZUio4uYo6Ic6vFmH3/diuW6ktmWQ9YV09aMNKs0E8P
uqIpoV+l7VUanBxGfHGd0TmQxox9x/j1dUfSQCZ5XmCWVsjOs99i4rEtMWXCjN4c
uyRYzNarTxnRCm1SPvXou/uMoJk1PKM4ovppJ0HNiTIgcg22RqPtFD7WnK6tRNwj
jDs/HCl3xTY=
=UAlv
-----END PGP SIGNATURE-----