BIND Operational Notification: A party that is allowed control over zone data can overwhelm a server by transferring huge quantities of data [CVE-2016-6710]
mcnally at isc.org
Thu Jul 7 22:58:35 UTC 2016
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: 1.0
Posting date: 07 July 2016
Program Impacted: BIND
Versions affected: 9.0.x -> 9.9.9-P1, 9.10.0 -> 9.10.4-P1, 9.11.0a1 -> 9.11.0b1
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
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.
Do you still have questions? Questions regarding this advisory
should go to security-officer at 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.
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.
(c) 2001-2016 Internet Systems Consortium
More information about the bind-announce