The "KeyTrap" DNS vulnerability

[Posted February 20, 2024 by corbet]

DNS resolvers (those that handle DNSSEC, at least) are almost uniformly vulnerable to an exploit that has been named "KeyTrap". In short, the right type of packet can send a DNS system into something close to an infinite loop, taking it out of service indefinitely.

With just a single DNS packet, hackers could paralyze all common DNS implementations and public DNS providers. Exploiting this attack would have serious consequences for any application that uses the internet, including the unavailability of technologies such as web browsers, email and instant messaging. This devastating effect prompted major DNS vendors to call KeyTrap "The worst attack on DNS ever discovered"

Some more information and pointers to updates can be found on the CVE-2023-50387 page; some distributors have been faster to get updates out than others.

(Thanks to Dave Täht).

The "KeyTrap" DNS vulnerability

Posted Feb 20, 2024 20:04 UTC (Tue) by h2g2bob (subscriber, #130451) [Link] (2 responses)

Debian CVE tracker is https://security-tracker.debian.org/tracker/CVE-2023-50387

I don't see NSD on the vulnerable list - maybe diversity of implementations (one of nsd's stated aims) is helping? (Or perhaps nobody thought to check it!)

The "KeyTrap" DNS vulnerability

Posted Feb 20, 2024 21:00 UTC (Tue) by bwelling (subscriber, #13189) [Link]

NSD is an authoritative name server, and KeyTrap affects recursive name servers.

The "KeyTrap" DNS vulnerability

Posted Feb 20, 2024 21:02 UTC (Tue) by mjeanson (subscriber, #72087) [Link]

nsd only implements an authoritative server, I think this vulnerability is limited to recursive servers.

The "KeyTrap" DNS vulnerability

Posted Feb 20, 2024 21:51 UTC (Tue) by rfunk (subscriber, #4054) [Link]

Happy to see that OPNsense already has a new release out addressing this. I'll be updating my firewall as soon as I get home today.

The "KeyTrap" DNS vulnerability

Posted Feb 21, 2024 9:37 UTC (Wed) by mtaht (subscriber, #11087) [Link] (5 responses)

There is a really long tail of dnsmasq implementations out there that have this problem. I do think most (99%) in the field do not have dnssec enabled, but perhaps the geek community adopted it more fully? Items in the article that point to how long a dns server can be disabled (like 17 hours!!) seem to be based on hefty hardware, I think on weaker hardware, it would be weeks. From a single packet. :(

As one of the instigators of getting dnsmasq dnssec capable (starting 2012!), and a believer in the technology, I am sad to have so thoroughly missed this algorithmic attack. I can think of a dozen ways chained with other vulnerabities common in embedded devices - or merely in a web browser hitting the wrong url - even "modern" ones - that this can be nasty.

At one level, the rise of DOH in modern web browsers is putting a much lower load on the central DNS servers than ever before, but losing local dns to this attack will be a PITA for everything else.

I worry that dnssec is enabled in container deployments, also.

Patch now. I hope more mitigations are found. It does require a malicious entry in the DNS to make happen, so there is that.

The "KeyTrap" DNS vulnerability

Posted Feb 21, 2024 12:30 UTC (Wed) by npws (subscriber, #168248) [Link] (3 responses)

Looking at the paper, I doubt that a single *packet* could contain a sufficient amount of signatures to trigger this behaviour. The RFCs talk of packets when they refer to network packets, and messages when they refer to DNS protocol requests and responses. In this case they probably mean a single message, not a single packet.

Regarding the bug itself, I'm very surprised how something quite obvious could go unnoticed for so long.

The "KeyTrap" DNS vulnerability

Posted Feb 21, 2024 23:12 UTC (Wed) by cytochrome (subscriber, #58718) [Link]

Quite obvious... in retrospect.

The "KeyTrap" DNS vulnerability

Posted Feb 22, 2024 9:18 UTC (Thu) by rhowe (subscriber, #102862) [Link] (1 responses)

At least in the paper they refer to a DNS message:

"We show experimentally that an adversary using
a single DNSSEC signed DNS response can DoS resolver"

https://www.athene-center.de/fileadmin/content/PDF/Techni...

The "KeyTrap" DNS vulnerability

Posted Feb 22, 2024 9:19 UTC (Thu) by rhowe (subscriber, #102862) [Link]

Make that "DNS response". I guess the "preview your comment before posting" feature of LWN exists for a reason!

The "KeyTrap" DNS vulnerability

Posted Mar 1, 2024 21:22 UTC (Fri) by jch (guest, #51929) [Link]

> I do think most (99%) in the field do not have dnssec enabled, but perhaps the geek community adopted it more fully?

I could be wrong, but my impression is that at least part of the community have been quietly dubitative about DNSsec. I wouldn't be too worried.