CVE-2017-3142: An error in TSIG authentication can permit unauthorized zone transfers

Published Jun 29, 2017
·
Updated

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

Other sources

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 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 or accepting bogus NOTIFY packets. Affects BIND 9.4.0->9.8.8, 9.9.0->9.9.10-P1, 9.10.0->9.10.5-P1, 9.11.0->9.11.1-P1, 9.9.3-S1->9.9.10-S2, 9.10.5-S1->9.10.5-S2.

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 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 or accepting bogus NOTIFY packets. Affects BIND 9.4.0-9.8.8, 9.9.0-9.9.10-P1, 9.10.0-9.10.5-P1, 9.11.0-9.11.1-P1, 9.9.3-S1-9.9.10-S2, 9.10.5-S1-9.10.5-S2.

IBM

Affected Software

33 affected componentsFixes available
debian/bind9
1:9.11.5.P4+dfsg-5.1+deb10u71:9.11.5.P4+dfsg-5.1+deb10u91:9.16.44-1~deb11u11:9.18.19-1~deb12u11:9.19.17-1
redhat/bind<9.9.10
9.9.10
redhat/bind<9.10.5
9.10.5
redhat/bind<9.11.1
9.11.1
ISC BIND>=9.4.0<=9.8.8
ISC BIND>=9.9.0<=9.9.10
ISC BIND>=9.10.0<=9.10.5
ISC BIND>=9.11.0<=9.11.1
ISC BIND=9.9.0-p1
ISC BIND=9.9.3-s1
ISC BIND=9.9.10-s2
ISC BIND=9.10.5-p1
ISC BIND=9.10.5-s1
ISC BIND=9.10.5-s2
ISC BIND=9.11.1-p1
redhat Enterprise Linux Desktop=6.0
redhat Enterprise Linux Desktop=7.0
redhat Enterprise Linux Server=6.0
redhat Enterprise Linux Server=7.0
redhat Enterprise Linux Server Aus=7.3
redhat Enterprise Linux Server Aus=7.4
redhat Enterprise Linux Server Aus=7.6
redhat Enterprise Linux Server Eus=7.3
redhat Enterprise Linux Server Eus=7.4
redhat Enterprise Linux Server Eus=7.5
redhat Enterprise Linux Server Eus=7.6
redhat Enterprise Linux Server Tus=7.3
redhat Enterprise Linux Server Tus=7.6
redhat Enterprise Linux Workstation=6.0
redhat Enterprise Linux Workstation=7.0
Debian Debian Linux=8.0
Debian Debian Linux=9.0
IBM API Connect<=V10.0.8.0 - V10.0.8.9

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade debian/bind9 to a version that resolves this vulnerability.

    Fixed in 1:9.11.5.P4+dfsg-5.1+deb10u7Fixed in 1:9.11.5.P4+dfsg-5.1+deb10u9Fixed in 1:9.16.44-1~deb11u1Fixed in 1:9.18.19-1~deb12u1Fixed in 1:9.19.17-1
  2. Upgrade

    Upgrade redhat/bind to a version that resolves this vulnerability.

    Fixed in 9.9.10
  3. Upgrade

    Upgrade redhat/bind to a version that resolves this vulnerability.

    Fixed in 9.10.5
  4. Upgrade

    Upgrade redhat/bind to a version that resolves this vulnerability.

    Fixed in 9.11.1
  5. Upgrade

    Upgrade BIND 9 to a version that resolves this vulnerability.

    Fixed in 9.10.5-P2
  6. Upgrade

    Upgrade BIND 9 to a version that resolves this vulnerability.

    Fixed in 9.10.5-S3
  7. Upgrade

    Upgrade BIND 9 to a version that resolves this vulnerability.

    Fixed in 9.11.1-P2
  8. Upgrade

    Upgrade BIND 9 to a version that resolves this vulnerability.

    Fixed in 9.9.10-P2
  9. Upgrade

    Upgrade BIND 9 to a version that resolves this vulnerability.

    Fixed in 9.9.10-S3
  10. Compensating control

    Mitigate by configuring Access Control Lists (ACLs) that require BOTH (1) address range validation and (2) TSIG authentication in parallel for zone transfers/updates (see ISC KB AA-00723: Using ACLs with both addresses and keys).

Event History

Jun 30, 2017
Data Sourced
04:21 AM
SeverityAffected Software
Jan 16, 2019
CVE Published
via MITRE·08:00 PM
Data Sourced
via MITRE·08:00 PM
RemedyDescriptionSeverityWeakness
Jul 7, 2026
Data Sourced
via IBM·12:00 AM
DescriptionAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2017-3142?

CVE-2017-3142 is classified as a high-severity vulnerability affecting BIND DNS servers.

2

How do I fix CVE-2017-3142?

To fix CVE-2017-3142, update your BIND software to a version that is not affected, such as 1:9.11.5.P4+dfsg-5.1+deb10u7 or later.

3

What versions of BIND are affected by CVE-2017-3142?

CVE-2017-3142 affects various BIND versions, including those prior to 9.11.5 and earlier versions like 9.10.5.

4

Can CVE-2017-3142 be exploited remotely?

Yes, CVE-2017-3142 can be exploited remotely by attackers who can send crafted requests to the DNS server.

5

Is authentication via TSIG sufficient in BIND for CVE-2017-3142?

No, relying solely on TSIG for authentication is insufficient as CVE-2017-3142 can bypass this protection.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203