01 November 2022 at 18:54 UTC
Updated: 02 November 2022 at 10:50 UTC
Punycode-related flaw fails the logo test
UPDATED 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.
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.
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.
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.
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.
Storm in a teacup
Vendors and operators should update their dependencies on OpenSSL to 3.0.7 but this is not urgent, in most scenarios.
Infosec luminary H D Moore pointed out that much of the speculation about the vulnerability was completely wrong.
“The issue is memory corruption in the punycode decoder; impacts clients talking to malicious servers, servers with client cert validation talking to malicious clients. code is only reachable post-signature validation,” Moore said in a Twitter update.
Third party security experts are talking down the threat while pointing out there’s still a problem that needs addressing.
Mattias Gees, container product lead at Venafi, commented: “When OpenSSL first announced this patch was coming, I immediately thought back to major vulnerabilities of the past, such as Heartbleed and Log4j.
“However, this vulnerability has been downgraded from critical to high severity by OpenSSL, mainly because it doesn’t cause data leakage and the attack vector is relatively small.”
Gees added: “Servers that are on OpenSSL 3.0 and are using Client Authentication in a non-trusted environment – such as public facing servers – should patch immediately to ensure they don’t fall victim to DDoS attacks. Servers running in trusted environments should still be patched, but the urgency here is reduced.”
Some saw the funny side.
“Well, at least that #OpenSSL vuln got us fixated on something other than Elon and elections for a few days,” said infosec researcher Wade Baker.
This story was updated to add industry reaction