Every `named` instance configured to run as a recursive resolver maintains a cache database holding the responses to the queries it has recently sent to authoritative servers. The size limit for that cache database can be configured using the `max-cache-size` statement in the configuration file; it defaults to 90% of the total amount of memory available on the host. When the size of the cache reaches 7/8 of the configured limit, a cache-cleaning algorithm starts to remove expired and/or least-recently used RRsets from the cache, to keep memory use below the configured limit.
It has been discovered that the effectiveness of the cache-cleaning algorithm used in `named` can be severely diminished by querying the resolver for specific RRsets in a certain order, effectively allowing the configured `max-cache-size` limit to be significantly exceeded.
This issue affects BIND 9 versions 9.11.0 through 9.16.41, 9.18.0 through 9.18.15, 9.19.0 through 9.19.13, 9.11.3-S1 through 9.16.41-S1, and 9.18.11-S1 through 9.18.15-S1.
Metrics
CVSS Version: 3.1 |
Base Score: 7.5 HIGH Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Common Attack Pattern Enumeration and Classification (CAPEC)
CAPEC-ID: CAPEC Description: By exploiting this flaw, an attacker can cause the amount of memory used by a `named` resolver to go well beyond the configured `max-cache-size` limit. The effectiveness of the attack depends on a number of factors (e.g. query load, query patterns), but since the default value of the `max-cache-size` statement is `90%`, in the worst case the attacker can exhaust all available memory on the host running `named`, leading to a denial-of-service condition.