Was Heartbleed really that critical? Here’s why it wreaked havoc across the IT community

Secunia Research classifies vulnerabilities by rating the severity of vulnerabilities from 1: "not critical" to 5: "extremely critical."
Going by the PR Heartbleed received, you would be excused for thinking that what we were dealing with here was, indeed, "extremely critical."
But it was not, as vulnerabilities go. That rating we use for "remotely exploitable vulnerabilities that can lead to system compromise. Successful exploitation does not normally require any interaction and exploits are in the wild."

The Heartbleed vulnerability was in fact only rated as a 3 of 5 by Secunia: "moderately critical", which is typically used for "remotely exploitable Denial of Service vulnerabilities against services like FTP, HTTP, and SMTP, and for vulnerabilities that allow system compromises but require user interaction."
It gets this rating because it enables information retrieval from remote without any user interaction or authentication requirements.

Location, location – and bad timing!
So, how did it get so bad? Because of an unfortunate combination of timing and unsuccessful coordination.

Heartbleed is a vulnerability within the heartbeat extension of OpenSSL – a library used by the majority of applications to perform encryption of data. OpenSLL is used everywhere, even within Secunia. That’s the location.

The bad timing component is in the disclosure process (read Ben Grubb’s article for a comprehensive account of the timeline):
The vulnerability was initially discovered by Neel Mehta of Google and reported by Google on March 21st, directly to OpenSSL on April 1st. On April 2nd Finnish IT security testing firm Codenomicon discovers it separately, and notifies the National Cyber Security Centre Finland (NCSC-FI). OpenSSL prepares to release the patch and an embargo is imposed for April 9th, giving at least some vendors time to coordinate release of the upcoming patch.
On April 7th NCSC-FI reports Codenomicons finding to OpenSSL. OpenSSL decides that since two different entities had discovered the same vulnerability within such a small timeframe, leaving it unpatched represents too big a risk. They therefore commit the fix to the repository, and release the patches two days earlier than originally planned.
Concurrently, on April 7th a number of blog posts and tweets about Heartbleed hit the internet.
In the course of the week between the initial discovery by Google and the vendor advisory disclosure, and the release of the patch, a number of organizations such as Akamai, Facebook, and Cloudflare were aware of the vulnerability and have committed patches to their own services.
So, to sum it up: the unsuccessful coordination preceding the disclosure of the vulnerability meant that everybody had to play – and are still playing – catch-up, trying to contain the damage.
 

The impact
Smaller vendors with only a few vulnerable programs within their portfolio only had a few patches to roll out.
But for bigger vendors, like Cisco, IBM and HP, it was – and is – a very different story: they will be hard at work on this one, for some time yet.
Currently, Secunia has written Heartbleed-related advisories for more than 95 vendors and over 575 products – we are at 205 Secunia Advisories, published on products affected by Heartbleed.
So while, in strict vulnerability criticality rating terms as defined by Secunia, Heartbleed only rates as "Moderately Critical", the long term and follow-up impacts it has on IT teams and consumers worldwide arguably makes it a top contender for one of the worst vulnerabilities we have seen in a long time. Those more than 575 different products that Heartbleed has made vulnerable so far, are spread across a range of different types of products, and for technology vendors and IT teams alike, the efforts to patch up systems in response to Heartbleed is a multi-faceted and volatile project not focused on any particular area of technology.
To further complicate matters, patch managers need to keep a close eye on version control to avoid accidentally upgrading to a Heartbleed-vulnerable version of their enterprise software before a patched version becomes available.

A never-ending story?
On June 5th, OpenSLL released new versions that fixed a series of vulnerabilities, including a vulnerability within the handling of DTLS fragments, which can be exploited to cause a buffer overflow and potentially execute arbitrary code on servers running a vulnerable version of OpenSSL. This vulnerability has no clever name or received any significant PR yet, but that doesn’t mean that it is less critical than Heartbleed.

What next?
Moving forward we expect to continuously see administrators update to fixed versions as patches becomes available, revoking and re-issuing certificates, and to take various other steps that are applicable for their setup, as soon as possible. However, we are not yet at a stage where everybody can simply patch. Some vendors are still in the process of developing patches.

The most important first step for everyone is to identify and patch the vulnerable software that handles the most critical information and which is reachable from remote. After that, you should perform a risk assessment which comprises attack vector and criticality of the data you need to protect.

Stay Secure,
Kasper Lindgaard
Director of Research and Security

Source: Secunia