The OpenSSL Project, which runs the widely-used OpenSSL library, has announced it will issue a critical vulnerability patch on 1 November.
The announcement marks the first OpenSSL critical vulnerability patch since 2016, and only the second in the project’s history. Full details of the flaw will be revealed at the time of the patch to reduce the possibility of attackers reverse engineering to develop an exploit.
However, it has already been stated that the vulnerability does not affect versions earlier than OpenSSL 3.0, with the patch forming part of the 3.07 release. This appears to mean that devices which run versions before 3.0, which was released in 2021, should remain unaffected by the vulnerability.
“Given the number of changes in 3.0 and the lack of any other context information, such scouring is very highly unlikely,” said Mark J Cox, former head of product security at Red Hat and one of the co-founders of OpenSSL, responding to a question in his original announcement tweet.
While the 2016 flaw allowed for remote execution of code, it was only active for four days before being caught and patched. In contrast, the newly-announced vulnerability affects all versions after 3.0 which was released in September 2021.
OpenSSL is the most popular open source cryptography library in the world and is used by the majority of HTTPS websites as well as on a range of web servers. As such, a critical vulnerability within its code could represent a serious threat to a wide range of businesses, as well as to individual privacy online.
The OpenSSL Project policy states that in the event of an upcoming patch to a flaw rated ‘critical’ in severity, a warning will be made publicly available to notify users of the exact date and rough time at which the patch will be made available.
Alongside this, select organisations will be given patches early, as well as briefings on the exact nature and seriousness of the flaw.
Some are already drawing comparisons between the upcoming announcement and 2014’s Heartbleed vulnerability, tracked as CVE-2014-0160, which garnered widespread media attention and concern in 2014 as it allowed threat actors to view data on any website utilising OpenSSL.
The financial services survival guide
How uncertainty and disruption is forcing financial services to innovate
It is also likely to add to growing fear of using open source solutions amongst companies, especially in the wake of the damaging Log4Shell vulnerability.
“The announcement of the new OpenSSL critical vulnerability immediately brought back not-so-fond memories of Heartbleed or - more recently - the Log4J vulnerability,” said Mattias Gees, container product lead at Venafi.
“Heartbleed had a significant impact on all operations teams worldwide, and since then IT infrastructure has become ten times more complicated. The attack vector has become a lot larger, and rather than just having to examine their VMs, organisations need to start preparing to patch all their container images in response to this announcement.
“We also now know that OpenSSL versions prior to 3.0 are not impacted, and a lot of operating systems use OpenSSL 1.1, so these environments won’t be impacted. This knowledge will allow cybersecurity and operations teams to dismiss large sections of their infrastructure, and hopefully make the impact of this vulnerability smaller than initially expected. But platform engineering teams should keep investing in better auditing of their environments and their dependencies for the next threat, which is always just around the corner.”
What was the Heartbleed vulnerability?
In 2014, security researchers discovered a flaw within the OpenSSL software library, which could be exploited by threat actors in order to track the activity of targets online, as well as serruptiously steal data entered on web pages. At the time of identification, some researchers worried that Heartbleed may have been exploited in the wild since 2012.
This was possible due to a coding error in the ‘heartbeat’ extension within OpenSSL, through which users could test transport layer security (TLS) encryption by sending data (typically a text string) and an integer representing the number of characters in the string to a computer or server device, which would then ‘echo’ the string back exactly.
As it was possible to send a string of a length equivalent to 64 KiB of data, that much memory was reserved for returns using the extension. However, it was discovered that if users only sent a nominal amount of data, but a length figure equal to 64KiB, the computer at the end would echo back the data sent, along with 64-1KiB of data from its memory buffer. This could reveal passwords entered, private server keys, sensitive user cookies — whatever happened to be in the memory at the time of the request.
As a result, threat actors were unable to specify precisely what data they would expose through each attack, but through repeat executions were able to invisibly monitor activity on any website which used OpenSSL, and exfiltrate data without any possibility of detection.
Given the scale at which OpenSSL is used throughout the internet, from financial services to critical backend apps, the Heartbleed vulnerability prompted considerable alarm within the cyber security community. Although a fix was quickly released, the fact that attacks carried out using the vulnerability left no trace made it hard to say for certain just how far reaching its impact was, and whose data has been stolen.
