CVE-2023-50387 (also known as “KeyTrap”) is a significant flaw in the DNSSEC (Domain Name System Security Extensions) protocols. It affects how DNS servers process digital signatures (RRSIG records) and cryptographic keys (DNSKEY records), as described in RFC 4033, RFC 4034, RFC 4035, RFC 684, and related RFCs.

This vulnerability lets remote attackers exhaust server CPU by sending carefully crafted DNSSEC responses. If a DNSSEC zone (the authenticated area of DNS) is loaded with many keys and signatures, the protocol forces the DNS server to perform *combinatorial verification*—matching each key to each signature. This can severely impact CPU performance, resulting in denial of service.

Let’s break it down with simple explanations, code samples, and practical exploit scenarios.

What is DNSSEC?

DNSSEC adds cryptographic signatures to DNS records. Besides normal records (like A, AAAA, MX), DNSSEC zones have:

DS records — signatures linking to child zones

Resolvers and validating DNS servers check if RRSIGs can be verified using one of the DNSKEYs.

According to the protocol

- A DNSSEC-signed record (e.g., an A record) can have *multiple RRSIGs* (for various algorithms or expiration times).
- Each RRSIG must be verified against all DNSKEY records of the right type (matching the cryptographic algorithm).

This means, if a domain operator configures N DNSKEYs and M RRSIGs for a record set, the server may need to attempt up to N x M cryptographic signature verifications per query.

Some protocol wording basically *requires* trying all possible combinations until a match is found. Attackers can craft zones (or responses) with large numbers of keys and signatures, knowing the validator will do far more work, consuming CPU and potentially crashing under load (DoS).

100 RRSIG records (over the same RRset)

Upon receiving a DNSSEC query, the resolver/validator may have to check all 1,000 combinations.

Here’s some Pythonic pseudocode (simplified) that shows what a DNSSEC validator might do when faced with these records:

dns_keys   = [parse_dnskey(key) for key in dnskey_rrset]
rrsig_list = [parse_rrsig(sig) for sig in rrsig_rrset]
rrset      = rrset_records # the actual DNS data (e.g., A records)

valid_signature_found = False

for sig in rrsig_list:
    for key in dns_keys:
        if key.algorithm == sig.algorithm and key.key_tag == sig.key_tag:
            if verify_signature(rrset, sig, key):
                valid_signature_found = True
                break
    if valid_signature_found:
        break

if not valid_signature_found:
    raise Exception("No valid DNSSEC signature found!")

In an attack scenario, with many signatures and keys, verify_signature() may be called hundreds or thousands of times for a single DNS response, burning a huge amount of CPU.

Flood them with queries for those records (e.g., using a botnet).

This can quickly exhaust CPUs, causing slowdowns or crashes for the DNS service—effectively a denial of service.

Real-World References

- Original CVE Description (MITRE)
- KeyTrap vulnerability page (SIDN Labs)
- DNS-OARC Discussion
- ISC BIND Security Advisory
- PowerDNS Advisory
- Unbound Advisory

Suppose the attacker’s zone is set up

malicious.example.   300 IN DNSKEY 257 3 8 ( AwEAAbc...fakeKey1 )
malicious.example.   300 IN DNSKEY 257 3 8 ( AwEAAbc...fakeKey2 )
...
malicious.example.   300 IN DNSKEY 257 3 8 ( AwEAAbc...fakeKey100 )

malicious.example.   300 IN RRSIG A 8 3 ... <signature1>
malicious.example.   300 IN RRSIG A 8 3 ... <signature2>
...
malicious.example.   300 IN RRSIG A 8 3 ... <signature100>

If validators receive a query for malicious.example. A + DNSSEC, they’ll fetch and attempt to validate the 100 keys × 100 sigs = 1 million signature checks!

A simple shell command to repeat queries might look like

# This *will* harm the validator if the attacker controls malicious.example
while true; do dig @target_dns_server malicious.example. A +dnssec; done

Most DNS vendors released patches in early 2024. Solutions include

- Capping the number of signature and key combinations per response. Example: Unbound introduced limits (see the advisory).

Early exit: aborting validation once a certain limit is hit.

- Monitoring and alerting for abnormal CPU usage/spikes from validation.

Non-standard zones (as in the exploit) are rare in the real world, but patches protect production servers from would-be attackers.

Summary

CVE-2023-50387 (“KeyTrap”) is a classic protocol-level vulnerability: it’s not a bug in a specific DNS server, but a problem in how DNSSEC is designed. Attackers can exploit legitimate protocol features (lots of keys/signatures) to tie validators up in complex, CPU-eating operations, causing denial-of-service conditions.

Consider limiting DNSSEC RRset complexity or rate-limiting queries

The KeyTrap bug highlights how security protocols must always balance between necessary complexity and safe, predictable resource usage.

If you’re interested in the nitty-gritty details, see

- SIDN Labs KeyTrap blog
- Unbound advisory
- DNS-OARC discussion

Timeline

Published on: 02/14/2024 16:15:45 UTC
Last modified on: 02/21/2024 13:15:07 UTC