Blog

Heartbleed was special. It was one of the first security issues to have been given a “name” in advance of publication, rather than just being assigned a CVE number (and possibly a nickname adopted by the industry after the announcement). It was easy to exploit, left no obvious traces in logfiles (unless some sort of network intrusion detection system was in place), and potentially leaked anything from personal data and user credentials through to private keys. The simplicity of the exploit meant a coordinated response across many operating systems, network appliances, and software and hardware vendors was needed.

Sometimes it feels like the rate of vulnerability announcements since Heartbleed has increased. That’s not the whole story.

Firstly, in the wake of Heartbleed, the industry as a whole has recognised that there are a large number of software libraries which are crucial infrastructure. These are the security building blocks of many, many systems. Cryptography is a particularly challenging technical element of computer security: a shoddy random number generator, re-use of a key, timing attacks, poorly understood protocols — what seem like little mistakes that are hard to detect can become the very weak link in a chain that is then easily broken. Established libraries like OpenSSL — a project that has been around since the 1990s — are not “sexy new projects”. Maintaining open source software like this can be a thankless task (just ask the team behind the NTP project). And after Heartbleed the industry has begun to recognise this.

Heartbleed crystallised security researchers, and suddenly lots of eyes were on the massive codebase of OpenSSL. This has led to a lot more eyes looking for bugs, and a lot more bugs being spotted. In the words of Linus Torvalds, “Given enough eyeballs, all bugs are shallow.”

Some efforts, such as LibreSSL, have forked the OpenSSL project codebase because they feel that is the only way they would have the freedom to tear out old cruft without the constraints that perfect backward compatibility might require. In evaluating any code that is being ripped out, the LibreSSL developers are helping the OpenSSL project to audit its code for vulnerabilities. Several bugs have been found this way, and numerous others avoided, including the most recent “alternative chains certificate forgery”.

Other teams, such as BoringSSL started at Google, have their own forks of OpenSSL, or have begun writing their own implementations of TLS completely from scratch. In so doing, they have also written their own protocol testing software. They’ve also applied the skills of other researchers within Google, such as Michal Zalewski, who developed numerous software fuzzing tools. Again, those tools have been turned on OpenSSL and so have discovered new issues.

In addition to there being more eyes on projects like OpenSSL, there is undeniably a PR factor. A company or security team that can find a large-scale high-severity vulnerability will get credited. Their name will be mentioned in almost all of the IT press covering the story. And if they have named it, designed a logo, and built a website with easily digested information than might be contained in a CVE, that’s a lot of “Google juice” from news publications and social media. You can’t get better search engine optimisation than thousands and thousands of highly relevant links.

Today, after about a week of embargo, the most recent SSL hole was disclosed. Despite being “high severity”, there wasn’t a fancy name or logo. Why not?

CVE-2015-1793 was mitigated largely because many of the popular Linux distributions had not yet included versions of OpenSSL which were vulnerable. This somewhat limits the PR-worthiness. It is also possible that the researchers who discovered it simply weren’t the “type” to seek so much attention — or possibly they are as fed up with cutesy names, logos and press-release-ready websites for single vulnerabilities.

So it’s 2015: are there more security holes than ever? In July 2015, the CVE Editorial Board changed the syntax of the CVE numbers to accommodate more than 10000 vulnerabilities per year. So on the one hand, there are more security holes than ever. But there is also a greater volume of software than ever before, and there are more researchers looking at its security both within development teams and independently. And software and network security will only get more complicated as technology becomes more pervasive in our lives. The future “Internet of Things” is a challenging environment for security, as technology and personal privacy become ever more intertwined.