CVE-2023-2828 - Exploiting BIND’s Cache Cleaning Weakness to Exceed max-cache-size

BIND is the most widely used DNS server—powering much of the global internet’s name resolution. Like many complex systems, its real-world security depends not just on core code, but also on the subtle behavior of its performance features. CVE-2023-2828 is a newly discovered issue where an attacker can force BIND’s named caching resolver to use far more memory than its max-cache-size setting, thanks to a weakness in the cache-cleaning algorithm. In this article, we’ll break down how it works, show code snippets, and review what makes this issue so serious.

What Exactly Is CVE-2023-2828?

When BIND runs as a recursive DNS resolver, it keeps a local database of recently resolved answers—called RRsets (Resource Record sets). This cache's maximum size is set with BIND’s max-cache-size option, or to 90% of system RAM by default. To avoid blowing up server memory, BIND is supposed to start cleaning its cache as it nears this limit, evicting expired or least-used RRsets.

But here’s the catch: By sending queries for clever RRsets, in a certain order, an attacker can overwhelm this cleaning process. In effect, BIND can be tricked into consuming much more memory than the configured maximum, potentially causing Denial of Service (DoS) or server slowdowns.

How the BIND Cache Cleaning Works—and Fails

Each time named answers a DNS query recursively, it stores the result in an internal cache, something like:

; Example named.conf setting
options {
    max-cache-size 256m;
};

When cache size hits 7/8 (about 87.5%) of the set value, BIND starts removing records that are expired or least-used.

But the core of CVE-2023-2828 is this:  
If DNS queries are crafted in a special order, the cache cleaning stops working efficiently. Old and unused entries stay in memory, and BIND’s cache can balloon past the configured maximum, using up system RAM.

!BIND DNS Cache Overflow Diagram
*An attacker queries for RRsets in a way that disables cache eviction, causing memory use to exceed max-cache-size*

Exploit Details: How an Attacker Can Abuse This

Let’s look at how one could actually *exploit* this weakness.

Attacker identifies a BIND instance running as a recursive resolver, with a max-cache-size set.

2. Crafts special DNS queries for many unique domains/resource records.

Each new RRset increases the cache usage.

4. By ordering the queries and keeping frequently-accessed entries just active enough, the usual cache eviction is thwarted.
5. Result: BIND’s max-cache-size is exceeded, RAM usage grows unchecked, potentially impacting system stability.

Here’s a simplified Python snippet (using dnspython) to simulate such traffic

import dns.resolver
import random
import string

resolver = dns.resolver.Resolver()
resolver.nameservers = ['TARGET.BIND.SERVER.IP']

while True:
    # Generate a unique random subdomain
    subdomain = ''.join(random.choices(string.ascii_lowercase, k=10)) + ".attacker.com"
    try:
        resolver.resolve(subdomain, 'A')
    except:
        pass

Real-World Impact

- Denial of Service (DoS): Server can be forced to consume all memory, leading to process kill or system hang.
- Unreliable DNS: May drop queries or provide slow responses, affecting web/email/critical infra.
- Shared DNS/Tenant environments: A single user could negatively affect all users on the system.

How to Fix or Mitigate

Patches & Upgrades:  
ISC released patched versions after June 2023.  
- ISC BIND 9 Security Fixes

Workarounds:

Reduce max-cache-size if resource exhaustion is a concern.

- Monitor/alert on excessive memory usage.

Recommended best practice:

References

- ISC Advisory: CVE-2023-2828 - Cache cleaning may leave memory limit enforced ineffectively
- NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2023-2828
- BIND Official Downloads: https://www.isc.org/download/

TL;DR

CVE-2023-2828 shows that DNS isn’t just about who resolves what—it’s also about *how* cache management keeps servers safe. If you run BIND as a resolver, update now, and keep a close eye on memory limits. Attackers don’t always smash down the door; sometimes they just sneak enough junk through it to fill your house up!

*Stay safe, keep services patched, and always monitor your infrastructure’s health.*

Timeline

Published on: 06/21/2023 17:15:00 UTC
Last modified on: 07/21/2023 19:19:00 UTC