From https://bugzilla.redhat.com/show_bug.cgi?id=1466193: An attacker who is able to send and receive messages to an authoritative DNS server and who has knowledge of a valid TSIG key name for the zone and service being targeted may be able to manipulate BIND into accepting an unauthorized dynamic update. A server that relies solely on TSIG or SIG(0) keys with no other address-based ACL protection could be vulnerable to malicious zone content manipulation using this technique. Workarounds: The effects of this vulnerability can be mitigated by using Access Control Lists (ACLs) that require both address range validation and use of TSIG authentication in parallel. For information on how to configure this type of compound authentication control, please see: https://kb.isc.org/article/AA-00723/0/Using-Access-Control-Lists-ACLs-with-both-addresses-and-keys.html. Administrators who have made use of named.conf option "update-policy local;" should refer to the Administrator Reference Manual (ARM) for details of the automatic update policy that will be established and to assess whether or not this conveys any additional risk to their server. (Note that this option is not enabled by default). Upstream patch: https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=581c1526ab External References: https://kb.isc.org/article/AA-01503 From https://bugzilla.redhat.com/show_bug.cgi?id=1466189: An attacker able to send and receive messages to an authoritative DNS server may be able to circumvent TSIG authentication of AXFR requests via a carefully constructed request packet. A server that relies solely on TSIG keys for protection with no other ACL protection could be manipulated into: * providing an AXFR of a zone to an unauthorized recipient * accepting bogus Notify packets An unauthorized AXFR (full zone transfer) permits an attacker to view the entire contents of a zone. Protection of zone contents is often a commercial or business requirement. If accepted, a Notify sets the zone refresh interval to 'now'. If there is not already a refresh cycle in progress then named will initiate one by asking for the SOA RR from its list of masters. If there is already a refresh cycle in progress, then named will queue the new refresh request. If there is already a queued refresh request, the new Notify will be discarded. Bogus notifications can't be used to force a zone transfer from a malicious server, but could trigger a high rate of zone refresh cycles. Workarounds: The effects of this vulnerability can be mitigated by using Access Control Lists (ACLs) that require both address range validation and use of TSIG authentication in parallel. For information on how to configure this type of compound authentication control, please see: https://kb.isc.org/article/AA-00723/0/Using-Access-Control-Lists-ACLs-with-both-addresses-and-keys.html. (Note that this technique will not be effective against bogus Notify packets if an attacker is able to reach the target DNS server whilst using a spoofed sending address). Upstream patch: https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=581c1526ab External References: https://kb.isc.org/article/AA-01504 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
bind and bind-tools 9.11.1-P3 have just been added
@arches, please test and mark as stable, thank you! Daj'Uan (mbailey_j) Gentoo Security Scout
amd64 stable
ia64 stable
alpha stable
arm stable
sparc was dropped to exp. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5901d8f716555a1479f12313a2925fcadd177a9
x86 stable
Re-adding amd64: You forgot to stabilize =net-dns/bind-tools-9.11.1_p3.
ppc64 stable
ppc stable
sparc stable
HPPA was missed...
hppa stable
GLSA Vote: No Tree is clean.
