Last Monday, OpenSSL core team member Mark J Cox, delivered some, grim, but somewhat expected news on OpenSSL’s mailing list — A new version of OpenSSL is due to be released this Thursday 9th July, fixing a single security defect classified as “high” severity.
OpenSSL is a widely used open-source toolkit for implementing the SSL/TLS protocols, as well as a general purpose cryptography library which is commonly used to encrypt Internet communications using SSL/TLS.
Anyone recalling the infamous “Heartbleed” (CVE-2014-0160), a vulnerability that got so much coverage it even ended-up in the mainstream media, will remember the rush many system administrators had to update OpenSSL on their systems — and with good reason; attackers started to exploit the Heartbleed bug within less than 24 hours after its public disclosure.
So is this new mystery bug another Heartbleed? Will it affect such a wide array of services and devices? Given this post by the same Mark J Cox on RedHat’s Security Blog, it might be the next one; but maybe not — understandably, the OpenSSL core team remain tight-lipped about further details so far. This is likely to provide enough time for testing, code review and crucially, for vendors and package maintainers to get ready for a unified release of the patch on Thursday. However, as we’ve seen with Heartbleed, such vulnerabilities can take some organizations a really long time to patch.
This incident continues to fuel the open-source software security debate. OpenSSL is one of the many underfunded open-source software projects that are being relied on in millions of organizations and governmental institutions around the world handling critical infrastructure and sensitive information; and it seems like history could really be set to repeat itself with the disclosure of this new OpenSSL bug.
After the massive repercussions Heartbleed caused, the Linux Foundation announced a three-year initiative with at least $3.9 million to help under-funded open-source projects including OpenSSL; but is this enough?
Some have decided to take a different route by either forking (copying source code from one software package and develop it independently) OpenSSL with projects such as OpenBSD’s “LibreSSL” and Google’s “BoringSSL”, or creating streamlined implementations like Amazon’s recently announced “s2n” library.
Either way, OpenSSL’s popularity and ubiquity, combined with it’s lack of funding, could come back to haunt it yet again — We’ll need to wait and see.