CVE-2017-3142
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Summary
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.
Affected Software
| Vendor | Product | Version Range | Status |
|---|---|---|---|
| ISC | BIND 9 | 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 | affected |
Weaknesses
- 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 conjunction. 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 may not be effective against bogus NOTIFY packets if an attacker is able to reach the target DNS server whilst using a spoofed sending address).
ADP Enrichment
CVE Program Container
Additional References
- https://access.redhat.com/errata/RHSA-2017:1680
- https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US&docId=emr_na-hpesbux03772en_us
- https://access.redhat.com/errata/RHSA-2017:1679
- http://www.securityfocus.com/bid/99339
- http://www.securitytracker.com/id/1038809
- https://www.debian.org/security/2017/dsa-3904
- https://kb.isc.org/docs/aa-01504
- https://security.netapp.com/advisory/ntap-20190830-0003/
References
- https://access.redhat.com/errata/RHSA-2017:1680
- https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US&docId=emr_na-hpesbux03772en_us
- https://access.redhat.com/errata/RHSA-2017:1679
- http://www.securityfocus.com/bid/99339
- http://www.securitytracker.com/id/1038809
- https://www.debian.org/security/2017/dsa-3904
- https://kb.isc.org/docs/aa-01504
- https://security.netapp.com/advisory/ntap-20190830-0003/
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.