OpenSSL encryption protocol is a “headlines star” once again after OpenSSL Project has released a grim-looking Security Advisory listing as many as six important security issues and patches for them.
The cyberworld is still cleaning its feathers after the #Hearbleed mess in April. News about the discovered vulnerabilities, as one could expect, led to a not-so-minor storm in social networks, although media outlets are probably yet to react appropriately.
But what would the appropriate reaction would be? Actually, none of the discovered vulnerabilities seem to be a match for Heartbleed: At least it won’t be that widely spread (and, most likely, won’t make a necessity to change all passwords this time). This is good news.
The bad news: The most serious vulnerability ChangeCipherSpec Injection Vulnerability (CVE-2014-0224) had been there since the first release of OpenSSL – i.e. since 1998.
How dangerous is this? According to dry language of OpenSSL’s security advisory, “An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server.”
In practice, MITM attacks are not necessarily easy to launch; this time it will take an attacker compromising some open WiFi-spot (say, a router in a local café) in order to strip the encryption from the information sent through it. “There are risks of tampering with the exploits on contents and authentication information over encrypted communication via web browsing, e-mail and VPN, when the software uses the affected version of OpenSSL,” says Lepidum, a company which employee Mashashi Kikuchi is credited with the bug discovery and initial reporting.
Also in practice, TOR project reports to be affected and recommends to update packages as soon as they are “available”.
More scrutiny over OpenSSL will reveal – and allow to fix! – more bugs.
Tweet
It is necessary to mention, though, that the attack can only be performed if both a client and a server are vulnerable. OpenSSL advisory reports that while all clients are vulnerable, Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Still, users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution either.
Well, for 16 years this important vulnerability hadn’t been discovered by its developers or any experts reviewing the code. At least officially. How this is possible?
According to Mashashi Kikuchi, a security researcher who reported the bug and provided the initial patch, “The biggest reason why the bug hasn’t been found for over 16 years is that code reviews were insufficient, especially from experts who had experiences with TLS/SSL implementation. If the reviewers had enough experiences, they should have been verified OpenSSL code in the same way they do their own code. They could have detected the problem“.
There were at least two occasions when this could have happened, but until now this bug stayed under the radars. It’s only a matter of hope now, that someone with less purity of intent hasn’t found it before Mashashi Kikuchi.
The rest six vulnerabilities are seemingly less dangerous, and have little to do with encryption per se. DTLS invalid fragment vulnerability (CVE-2014-0195) allows for a buffer overrun attack to be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This one is potentially exploitable to run arbitrary code on a vulnerable client or server. The only application affected are those using OpenSSL as a DTLS client or a server. And the rest of the reported bugs can only be used to launch DoS attacks, without compromising the encrypted data.
Still these vulnerabilities cannot (and, hopefully, would not) be disregarded.
What does this mean for business and system administration? For starters – prompt update of OpenSSL software wherever it is used. It is nice to know that non-OpenSSL clients, such as IE, Firefox, Chrome on Desktop and iOS, Safari, etc. aren’t affected.
Unfortunately (or not) this may well mean that in the near future more vulnerabilities will be discovered and disclosed. The Heartbleed fallout led to a more scrupulous scrutiny of the OpenSSL code with Google, Amazon and several other tech companies lending a hand with money and expertise.
The newly discovered six bugs, however dwarf-like they are in comparison to Heartbleed, may be just the beginning of the steady chain of head-ups for OpenSSL users. It is imperative that they are watched closely and all the patches are applied in a timely manner.
There are naysayers already, saying that the encryption on the Web – like privacy – is essentially dead, since there’s no reason to expect other encryption systems to be much more secure and nothing can make you safe.
“The fact of the matter is that nothing is foolproof. If fundamental flaws in one of the world’s most widely used encryption systems can go undiscovered for years, what other bugs are still lurking in the shadows in OpenSSL and other SSL systems? Who already knows about them but has chosen to keep quiet?” writes Adam Turner in his column in Sydney Morning Herald.
But on the other hand, some find this last batch of newly-discovered vulnerabilities rather encouraging: it means more responsible approach of OpenSSL developers and third-party experts to code reviews now: more scrutiny means less “shadows” where the bugs could be hiding.