In BIND 9.3.0 -> 9.11.35, 9.12.0 -> 9.16.21, and versions 9.9.3-S1 -> 9.11.35-S1 and 9.16.8-S1 -> 9.16.21-S1 of BIND Supported Preview Edition, as well as release versions 9.17.0 -> 9.17.18 of the BIND 9.17 development branch, exploitation of broken authoritative servers using a flaw in response processing can cause degradation in BIND resolver performance. The way the lame cache is currently designed makes it possible for its internal data structures to grow almost infinitely, which may cause significant delays in client query processing.
Metrics
CVSS Version: 3.1 |
Base Score: 5.3 MEDIUM Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
CWE-ID: CWE Name: Authoritative-only BIND 9 servers are NOT vulnerable to this flaw. The purpose of a resolver
s lame cache is to ensure that if an authoritative server responds to a resolver
s query in a specific broken way, subsequent client queries for the same tuple do not trigger further queries to the same server for a configurable amount of time. The lame cache is enabled by setting the "lame-ttl" option in named.conf to a value greater than 0. That option is set to "lame-ttl 600;" in the default configuration, which means the lame cache is enabled by default. A successful attack exploiting this flaw causes a named resolver to spend most of its CPU time on managing and checking the lame cache. This results in client queries being responded to with large delays, and increased likelihood of DNS timeouts on client hosts. Affects BIND 9.3.0 -> 9.11.35, 9.12.0 -> 9.16.21, and versions 9.9.3-S1 -> 9.11.35-S1 and 9.16.8-S1 -> 9.16.21-S1 of BIND Supported Preview Edition, as well as release versions 9.17.0 -> 9.17.18 of the BIND 9.17 development branch. Source: ISC
Common Attack Pattern Enumeration and Classification (CAPEC)