OpenSSL vulnerability downgraded to ‘high’ severity

Punycode-related flaw fails the logo test

A much-anticipated security update from OpenSSL landed today (November 1) but its impact appears to be considerably less than developers initially feared.

OpenSSL 3.0.7 tackles two vulnerabilities in the cryptographic library (tracked as CVE-2022-3786 and CVE-2022-3602, respectively) and both involve X.509 email address buffer overflows.

OpenSSL versions between 3.0.0 and 3.0.6 are affected by the flaws – both of which were anticipated as “critical”, but were eventually classified as “high” risk.

“The bugs were introduced as part of punycode decoding functionality (currently only used for processing email address name constraints in X.509 certificates),” an FAQ by the developers of OpenSSL explains.

Catch up on the latest encryption-related news and analysis

Last week developers of OpenSSL took the unusual steps of warning of the looming “critical” vulnerability, the first issue to reach this level of severity since the infamous Heartbleed vulnerability (CVE-2014-0160) eight years ago.

Heartbleed was a memory handling bug that created a means for attackers to steal secret keys, passwords, and sensitive personal information from vulnerable systems.

No Heartbleed?

The latest flaws initially appeared to present a remote code execution (RCE) risk comparable to Heartbleed, but subsequent testing work has shown that stack overflow protections on modern platforms mitigate against potential malfeasance.

And, for some Linux distros, the stack overflow only leads to a currently unused portion of memory – useless from an attacker’s perspective.

BACKGROUND Upcoming ‘critical’ OpenSSL update prompts feverish speculation

Other as-yet-unidentified platforms might turn out to be at risk of greater exposure, but for now the impact of systems that rely on the almost ubiquitous cryptographic library would appear to be limited to denial of service (i.e. crashed programs).

Both updates only affect OpenSSL 3.0.x, a release line that debuted in 2021 – another factor that limits the scope of the whole problem.

No logo

There’s no indication that either of the flaws have been abused but even so it makes sense to audit systems for potential exposure to vulnerable versions of OpenSSL 3.0.x and, of course, to update software stacks. Users operating TLS servers may consider disabling TLS client authentication, as a workaround short of patching.

It could also be time to stand down from any heightened alert state due to concern about the effect of another Heartbleed-style vulnerability.

This vulnerability hasn’t even been branded in any way – perhaps, to some, the ultimate diss. “The OpenSSL project has not named or created logos for either CVE,” the developers said.

RECOMMENDED SQLite patches 22-year-old code execution, denial of service vulnerability