Looking back at 2014, we see an abundance of vulnerabilities in Adobe Acrobat, Java, Windows, and others. The steady stream of disclosures came as a shock to no one.
What was surprising was the revelation of two very significant and widespread vulnerabilities: Heartbleed and Shellshock.
Heartbleed is a set of bugs in the popular open source security library, OpenSSL. If you haven’t heard of OpenSSL, don’t worry, it’s not usually exposed directly to the end user. But it does provide the security layer for the majority of websites.
This bug allows an attacker to access information stored in the memory of a server using OpenSSL. This level of access allows the attacker to compromise any connection to the server with minimal effort.
Shellshock is a bug in the near ubiquitous command line interpreter bash. Haven’t heard of bash either? Even if you don’t use it yourself, it’s probably on your system or a device that you’re using or connecting to right now.
This bug allows the attacker to very simply execute arbitrary commands on your system. To make matters worse, this attack takes only a few extra characters in a request and very little technical acumen.
Taken together, both of these bugs had a significant impact on how we view our IT infrastructure. Each of these bugs received national media attention due to their potential impact.
Worse yet, both bugs had been out in the wild for a long time. Heartbleed was 2 years old (source: Wikipedia, Heartbleed > History) when discovered. Shockingly (no pun intended…or at least admitted to) Shellshock was 25 years old (source: Wikipedia, Shellshock > Background) when it was uncovered.
To say that these events have reverberated through the security community is an understatement.
There has been much debate about the overall level of security of open source projects vs. closed source projects. The common misconception is that the code is open source projects is usually more secure.
That’s simply not true.
Any–and every–codebase has bugs and some number of security issues. Both closed and open source projects have a direct interest in reducing the number of bugs and issues in their code.
The reality is that the argument could be made that either is more or less secure. It entirely depends on the team developing the code, their commitment to quality, and their ability to deliver consistently.
The fallacy that open source is more secure comes from the fact that anyone can audit the code for security issues. That’s the key word “can.” That doesn’t mean that everyone or anyone actually does perform a security audit on the codebase.
While we’ve had serious vulnerabilities disclosed before, together Heartbleed and Shellshock highlight the fact that software is more integrated into our daily lives than most people realize.
Further, the software that provides the foundation for a lot of what we do may not be as secure as we assume
Because something works and has worked consistently for years doesn’t mean that there aren’t any vulnerabilities.
For closed source projects it’s up to the teams writing the code to review it and ensure that any issues are resolved.
Open source projects require a different approach. Because they are primarily volunteer-based, we need to make a concerted effort to tighten up the issues in these projects. We can see a fantastic example of this post-Heartbleed with the OpenSSL project where members of the community conducted a code audit and started some new initiatives to resolve the problems.
Closed source, open source, it doesn’t matter. If you’re developing code, you need to ensure that you’re doing your best to find and resolve any issues in your codebase.
If you’re deploying software, you have to make sure that you understand the dependencies between the components of your deployment. Furthermore, put mitigating controls in place to protect from any issues that do arise.
No strategy is perfect. Having layers of defense is the key to a successful security strategy. That strategy has to start with a strong core, the code itself.
Please add your thoughts in the comments below or follow me on Twitter; @marknca.