Is it the new Heartbleed or just a bleeding distraction?
Developers of the OpenSSL cryptography library have taken the unusual step of pre-warning that an update due to land next Tuesday (November 1) will fix a critical vulnerability.
The looming OpenSSL 3.x patch represent only the second time the project has addressed a flaw classified as ‘critical’. The only previous OpenSSL update of such elevated severity addressed the infamous Heartbleed vulnerability (CVE-2014-0160).
Heartbleed was a memory handling bug that opened the door for attackers to access secret keys, passwords, and sensitive personal information from vulnerable servers. At the time of its discovery eight years ago, experts from Netcraft estimated that the flaw affected 17% of SSL web servers or “half a million widely trusted websites”.
Little is known about the upcoming critical fix (OpenSSL 3.0.7), other than it is restricted to OpenSSL version 3.0, the latest release line of the software, and does not affect previous versions.
YOU MAY ALSO LIKE HyperSQL DataBase flaw leaves library vulnerable to RCE
OpenSSL 3.0.x only debuted in 2021, a factor that might limit the extent of the problems next week’s announcement will reveal. OpenSSL has been around since 1998 and most systems today are still built using earlier release lines.
No details of the upcoming patch or the critical flaw it tackles have been released. In the absence of any hard info, infosec Twitter has gone into overdrive with some speculating that the vulnerability might represent the “next Heartbleed”.
One security expert from Google, for example, has suggested on the basis of recent software commits and a blog post by the OpenSSL team that the update might relate to a denial-of-service (DoS) issue.
Feel the DHEat
This particular DoS bug – known as DHEat and previous confirmed to affect OpenVPN and SSH services – involves enforcing the Diffie-Hellman key exchange.
DHEat (AKA CVE-2002-20001) scores 7.5 on the CVSS 3.1 index, indicating high severity and falling somewhat short of critical.
On the face of it, an OpenSSL patch for DHEat would appear to be a poor candidate for a critical patch unless OpenSSL is particularly vulnerable. A recent OpenSSL blog post referencing DHEat makes it even more unlikely that the looming patch tackles this issue.
It seems more likely that a previously unknown vulnerability is at play, according to experts quizzed by The Daily Swig.
Brian Fox, CTO of Sonatype, told us that organizations should audit their code base for exposure to any vulnerability in OpenSSL 3.0.x, leaving them prepared to either patch or isolate vulnerable systems next week.
“In the first instance, it’s critical to find out where 3.x is used,” Fox said. “More importantly, it’s vital to get tooling in place to avoid having to audit and identify components manually every time.”
Fox went on to argue that speculation about the content of the upcoming fix were, at best, “unhelpful”. He said: “The speculation assumes that the fix is available in the publicly visible source and the advance notice gives attackers time to find it. This assumption may not be true. It is a best practice at some times to embargo the actual change until after the announcement for this exact reason.
“The team at OpenSSL consists of some of the foremost experts in handling high profile open source vulnerability disclosures and if they have determined this is the best course of action – to give advance notice – then I have faith in that decision.”
Professor Alan Woodward, a computer scientist at the University of Surrey, reasoned that the problem is unlikely to be related to the older vulnerability.
“If the OpenSSL vulnerability is truly critical as per their own definition, then it sounds dire,” Prof. Woodward told The Daily Swig. “If it’s the older vulnerability, I fear they may have cried wolf. It isn’t helpful to give so little information but as it is a tiny team I can see why.”
Prof. Woodward concluded: “I guess we’ll all have to wait until next week.”
YOU MAY ALSO LIKE GitHub patches bug that could allow access to another user’s repo