Row breaks out over true severity of two DNSSEC flaws – Source: go.theregister.com

Updated Two DNSSEC vulnerabilities were disclosed last month with similar descriptions and the same severity score, but they are not the same issue.

One, named KeyTrap (CVE-2023-50387) by Germany’s National Research Centre for applied cybersecurity (ATHENE), was described as “one of the worst ever discovered,” by Akamai exec Sven Dummer, because it could be used to disable large portions of the internet.

KeyTrap allowed a single DNS packet to deny service by exhausting the CPU resources of machines running DNSSEC-validated DNS services, such as those provided by Google and Cloudflare.

DNSSEC (Domain Name System Security Extensions) offers a cryptographic way to protect DNS interactions. But its implementation specification failed to account for the possibility of maliciously crafted packets that could force a responder to tie itself in knots doing obligatory calculations.

The other DNSSEC flaw, NSEC3-encloser (CVE-2023-50868), was found by Petr Špaček from the Internet Systems Consortium (ISC) and was also presented as a CPU exhaustion risk. But based on an analysis conducted by the ATHENE team, it now looks largely inconsequential.

Both earned a severity rating of 7.5 out of 10 under the Common Vulnerability Scoring System (CVSS) by MITRE, the nonprofit security outfit that operates US federally funded research and development centers.

The two flaws were also described in advisories from the ISC, maker of affected BIND 9 DNS software, using identical terms. The CVEs for KeyTrap and NSEC3-encloser each suggest the vulnerabilities can be exploited to conduct denial of service attacks.

Here’s how the ICS describes KeyTrap:

And here is its verbiage for NSEC3-encloser:

• ZenHammer comes down on AMD Zen 2 and 3 systems
• Tech trade union confirms cyberattack behind IT, email outage
• Mozilla fixes $100,000 Firefox zero-days following two-day hackathon
• GoFetch security exploit can’t be disabled on M1 and M2 Apple chips

But the two vulnerabilities are not comparable in terms of severity, according to Haya Schulmann, a professor of computer science at Goethe University Frankfurt, one of the ATHENE academics behind the KeyTrap research. By email, Schulmann told The Register that experiments indicate no denial of service through CPU exhaustion is possible with NSEC3 vulnerability.

Schulmann said the ATHENE team has published findings to that effect in a paper [PDF] titled “Attacking with Something That Does Not Exist: Low-Rate Flood with ‘Proof of Non-Existence’ Can Exhaust DNS Resolver CPU.”

The paper, she said, looks specifically at the impact of the NSEC3-encloser vulnerability and finds it is several orders of magnitude less taxing on CPU cores than KeyTrap.

“We perform extensive evaluations of NSEC3-encloser attack and find that it can create a massive increase in CPU instruction count on victim DNS resolvers,” the paper says. “This is much less than the recently disclosed KeyTrap attack, which creates a factor of 2,000,000 increase in CPU instructions count.”

The paper, we’re told, was shared with various DNS software vendors, including ISC, as of March 17 and has not yet generated any response.

The Register asked MITRE, which assigned the CVEs, to comment on concerns raised by Schulmann and her colleagues. We’ve not heard back.

Schulmann says she raised these concerns with MITRE, which according to her responded as follows:

Schulmann found this response troubling because it appears MITRE is suggesting that the evaluation of a vulnerability’s importance may vary, depending upon the documentation consulted.

“The response of MITRE implies that there are different perspectives on the vulnerability, encouraging the interested parties to read the entire technical report to understand that the description of MITRE is incorrect,” she wrote. “Scientific research derives conclusions based on an analysis and evaluations, and not on opinions and perspectives.

“While our technical report provides a detailed analysis and evaluations, the blog of ISC briefly describes both problems yet without any details. This response of MITRE also contradicts the information on NIST pertaining to the process of assigning vulnerabilities, since the process requires that the analysts use any available information to establish severity. As a result of MITRE ‘adopting one perspective,’ both the CVSS score and the descriptions of the CVEs are incorrect and are misleading.”

NIST did not immediately respond to a request for comment.

According to Schulmann, the two CVEs show there’s reason to doubt the correctness and quality control of MITRE vulnerability assessments and the NIST-run National Vulnerability Database that stores such information.

Schulmann argues that while it may be reasonable sometimes for MITRE to present the “perspective” of vendors in vulnerability reports, this should be with care because vendors may be tempted to downplay serious vulnerabilities to avoid negative publicity.

She cites the recent compromise of a Microsoft signing key as an example.

“That breach affected customers of Azure cloud products, and understanding the exact details of breach was essential for organizations to defend themselves,” she explained. “Nevertheless, there were concerns in the community that Microsoft held details of the breach back, downplaying the incident.”

Schulmann argues that MITRE and others tasked with the dissemination of security response information need to be more exacting in their vulnerability evaluations, even if that means vendor discomfort.

“It is critical that MITRE maintains professionality and neutrality in their assessment of the vulnerability information, so that the public can rely on it,” said Schulmann. “In particular, MITRE, as it is stated by NIST, should use any available information to base its assessment on.

“A lack of transparency and relying on a preferred perspective may not only create distrust between the actors, but it may also harm the overall security.” ®

Updated to add

In a statement provided to The Register after this story was filed, Matt Scholl, head of NIST’s computer security division said, “In general, we publish the Common Vulnerability Scores using the CVSS v3 specification and the information provided in the submitted CVE.

“This generates a ‘base score’ that could need refinement for context, use, risk tolerance and threat models at the local level.

“CVSS base scores are also about the technology and not the scale in which it might be used or deployed. If CVSSv3 Base scores seem ‘lax’ to a user, then we encourage the use of locality inputs to the score to be more meaningful to that user.”