OpenSSL Bug Wasn’t Awful, but It Still Needs Action
When the issue first came up late in October, hackles were raised, but now that the bug doesn't seem as destructive, we can breathe normally… almost
The entire world wide web depends on OpenSSL as it makes it possible for use the secure transport layer security or TLS over Linux, Unix, Windows and every other operating system. It also gets used to lock down secure communications and networking applications and devices. So, when someone cries Wolf! We cannot but sit up and take notice.
When Mark Cox, VP of Security at the Apache Software Foundation tweeted about an update to fix a “critical CVE”, there were concerns around how critical was critical? As it turned out, it wasn’t a critical error that could result in remote code execution (RCE) or anything close to being as horrid as all that.
It’s bad, but not all that bad
Of course, we don’t mean to demean the prognosis. The two bugs around email security come with an 8.8 rating that is considered high and could still cause trouble at the mill. Of course, this would be true if one happens to be on OpenSSL 3.0.0 to 3.0.6. Anything beyond OpenSSL 1.1.1 and 1.0.2 there’s nothing to worry about.
However, some wise men insist that just because the operating system uses an OpenSSL of newer vintage doesn’t mean that issues won’t perk up. There could be a case where applications or containers may use a vulnerable version, which means it would be a good idea to do a quick check on the code running in the background.
A report published on ZDNet quotes Brian Fox, co-founder and CTO at Sonatype to suggest that memory overflow bugs could lead to worse scenarios and this particular one appears to suggest that the level of difficulty for an exploit was quite high. Here is what he has to say: “The vulnerability requires a malformed certificate that is trusted or signed by a naming authority. That means that authorities should be able to quickly prevent certificates designed to target this vulnerability from being created, further limiting the scope.”
Heardbleed vulnerability is never easy
Jonathan Knudsen, Head of Global Research, Synopsys Cybersecurity Research is even more articulate about the issue. He quotes Bruce Schneier to remind us that on a scale of 1 to 10 the Heartbleed vulnerability was an 11 and says exposure by default to any software that uses a vulnerable version of the OpenSS: could be disastrous for any sort of security data stored in server memory.
However, one doesn’t need to get one’s hair on fire this time round. The vulnerabilities are serious but not of the same magnitude. Vulnerable servers would need to be requesting client certificate authentication, which is not the norm, and vulnerable clients would need to connect to a malicious server, which is a commonplace attack vector anyhow, he says.
He also advocates that if one doesn’t already know what open source components are in your software, consider implementing Software Composition Analysis posthaste. Once you know which software has a vulnerable version of OpenSSL, make a plan to update your software in priority order and work with your vendors to get updates to the software you acquire.
