BLOG

Open source security post Heartbleed

 

Heartbleed is one of the biggest and most publicized vulnerability of the last decade. The affected open source library, OpenSSL is one of the critical elements of the infrastructure the internet is based upon. According to estimates, approximately 66% of internet services users have been affected by this vulnerability.

 

In the last 15 years, open source projects have built an image based on security and reliability and the doctrine that supports this image is free access to the source code. The more people get to look at and analyze the code, the greater chances that bugs and vulnerabilities are discovered and fixed faster. Thereby, the users’ trust is built based on transparency. Having this advantage over the proprietary projects, the natural question that comes to mind is: what did not work in OpenSSL’s case?

Unfortunately, this vulnerability has proved that usually, users take the open source security for granted, based on the idea that more qualified people have already reviewed the code. What happens though when everyone thinks the same? We get to that point where developers rely on users or at least a part of them, to discover possible errors and the users rely on developers not to make any mistakes (or to discover them on their own).

The OpenSSL project, a tool the internet security infrastructure is based upon, is maintained by a group of developers from which most are volunteers, working on their own free time. Although this project has a great business impact for companies like Google, Yahoo or Microsoft, most of the funding that kept the project going came from individual donations of a few tens up to hundreds of dollars. Therefore, money, time and resource consuming activities such as impact analysis, code review and audit have been done at a superficial level or not at all. Nobody referred to these gaps until it was too late. At first, the blame was cast on the project developers, but then, when all the shortcomings of this project have surfaced, the general opinion was shifted. The community took the blame upon itself and started taking measure to prevent similar scenarios in the future.

Luckily, the exposure caused by Heartbleed did not reach the presumed catastrophic proportions. The patch was published in record time by the members of the community that were directly affected and the attempts to exploit the vulnerability after the publishing were isolated.

An important conclusion that came out of this crisis was the necessity of acknowledging the importance of Open SSL and other open source projects unrolling in the internet security infrastructure. The first step in this direction was taken by The Linux Foundation, which motioned a 3.9 million dollars fund designed to help underfinanced open source projects, with OpenSSL first on the list. Amazon, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, VMware and other such industry giants have announced their willingness to provide 100.000 dollars a year, for at least 3 years from now, for what they called the “Core Infrastructure Initiative”. Its purpose is to identify and adequately finance other critical open source projects, in order to avoid another Heartbleed.

Even though there were voices claiming that the open source security image has been tamed, the outcome was quite the opposite. The community understood that the main benefit of open source – free access to the source code – counts for nothing if no one takes advantage of it. It also realized that as projects get more complex and have more users, they need proportional funding and infrastructure.

 

Leave a Reply

Your email address will not be published.

We use cookies to deliver a cosy experience on our website.

The website is built over Wordpress and it uses plugins to display content as intended.

By accepting this notice, you consent to cookies on this device as per our Cookie Policy.

Some contents or functionalities here are not available due to your cookie preferences!

This happens because the functionality/content marked as “%SERVICE_NAME%” uses cookies kept disabled. To view this content or use this functionality, please enable cookies: click here to open your cookie preferences.