CVE-2017-3142 and CVE-2017-3143 bind: An error in TSIG authentication can permit unauthorized zone transfers.
This document (7021041) is provided subject to the disclaimer at the end of this document.
Environment
SUSE Linux Enterprise Server 11
SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Desktop 12
SUSE Linux Enterprise SDK 12
SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Desktop 12
SUSE Linux Enterprise SDK 12
Situation
The attack exploits a weakness in the TSIG authentication scheme and DNS servers who rely exclusively on this scheme are particularly vulnerable.
An attacker who can send to and receive from 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
Furthermore, if the attacker has knowledge of a valid TSIG key name for the zone and service being targeted, then it may be possible to manipulate BIND into accepting an unauthorized dynamic update.
This would effectively allow the attacker to inject arbitrary malicious content into the DNS server's master zones.
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.
An attacker who can send to and receive from 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
Furthermore, if the attacker has knowledge of a valid TSIG key name for the zone and service being targeted, then it may be possible to manipulate BIND into accepting an unauthorized dynamic update.
This would effectively allow the attacker to inject arbitrary malicious content into the DNS server's master zones.
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.
Resolution
The solution is install the security update SUSE provides for BIND as detailed on the respective SUSE CVE pages.
As a workaround to mitigate this problem, please change the configuration to apply the ACL restrictions as well as TSIG authentication, as are detailed in the additional information section below.
As a workaround to mitigate this problem, please change the configuration to apply the ACL restrictions as well as TSIG authentication, as are detailed in the additional information section below.
Cause
Additional Information
The effects of this issue can be mitigated by applying the defense-in-depth principle to harden
the server's configuration so that it applies ACL restrictions as well
as TSIG authentication.
The Internet Systems Consortium has provided further information on how to harden a server's configuration in that
regard at: 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).
For more details on Bind vulnerabilities, please reference the ISC knowledge base :
https://kb.isc.org/article/AA-00913
The Internet Systems Consortium has provided further information on how to harden a server's configuration in that
regard at: 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).
For more details on Bind vulnerabilities, please reference the ISC knowledge base :
https://kb.isc.org/article/AA-00913
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:7021041
- Creation Date: 29-Jun-2017
- Modified Date:03-Mar-2020
-
- SUSE Linux Enterprise Desktop
- SUSE Linux Enterprise Server
- SUSE Linux Enterprise Software Development Kit
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com
