On April 7, 2014, the world learned of what’s possibly the most severe security bug in the history of the Internet. It’s called Heartbleed.
Discovered simultaneously by Neel Mehta, a security researcher at Google, and Finnish security firm Codenomicon, the bug compromises a security protocol commonly used by devices and websites worldwide. Heartbleed makes it possible for a hacker to scrape data from memory – including passwords, bank account numbers, and anything else lingering inside.
The severity of the bug left many wondering how it could happen. OpenSSL, the security protocol in which bug was found, is used all over the world. It’s used not just in servers, but also routers and even some Android smartphones. You might think that some responsible party has a team of security researchers checking and double-checking the code but, in truth, OpenSSL is managed by a small group consisting mostly of volunteers.
Opening to OpenSSL
OpenSSL boasts its open-source origin in its name. Founded in 1998, the project was created to provide a set of free encryption tools for Internet servers. This was an important goal; encryption is critical and common. A free standard was needed to make sure it would be adopted as quickly as possible. The project was wildly successful, and quickly became one of the Internet’s most important security tools.
Yet, success did not result in expansion or profits. OpenSSL generates income only through support contracts, which provides access to troubleshooting and consulting from the organization itself.
A total of just 11 people, most of them volunteers, are responsible for a critical encryption standard.
This results in a predictably tiny staff. The “core team” is made up of only four individuals, and the development team adds seven more names to the list. That’s a total of just 11 people, most of them volunteers, responsible for a critical encryption standard. Only one of them, Dr. Stephen Hanson, focuses on OpenSSL entirely. Everyone else has another full-time job.
Steve Marquess, who manages the organization’s money, said it best. “The mystery is not that a few overworked volunteers missed the bug; the mystery is why it hasn’t happened more often.”
Mistakes were made
That’s what the entire crisis boils down to – a mistake. The error was introduced by Robin Seggelmann, a German volunteer working on an OpenSSL extension called Heartbeat. He submitted the code on New Year’s Eve, 2011, and it subsequently slipped through the review process. Heartbleed has existed, unknown to the public, for over two years.
Other members of the project double-check submitted code during the review, but mistakes happen, so it’s hardly a surprise that a bug eventually slipped through. Even multi-billion dollar companies like Microsoft and Cisco are hit by their fair share of embarrassing exploits.
The problem stems from allocating memory according to a value that can be defined by a request. If the user provides a valid input, the function works as intended. However, if an invalid request is made, the code dumps part of what’s in memory, including information that’s supposed to be secure and encrypted. This web comic also explains Heartbleed, should you deem a visualization to be helpful.
Some software engineers believe that the existence of the bug raises questions about the security of C, the code in which the Heartbeat extension was written. Though popular, C is a complex language that offers a lot opportunity for errors in memory management and the handling of values. A bug in another open-source SSL implementation, GnuTLS, cropped up a month before Heartbleed, and was also written in C. That bug was even older; the code responsible for it was added in 2005.
What’s the next step?
Human error is ultimately to blame for Heartbleed, but the fault doesn’t fall solely on the shoulders of a single coder. OpenSSL is free software used by Fortune 500 companies, governments and even military organizations, yet these outfits almost never contribute funding or manpower to the project.
Companies and governments seem very concerned, yet pledges of real support are ominously absent.
The world also must learn from this mistake. Using an open-source project without contributing to it is, in the long term, a recipe for disaster – particularly when the project is a critical part of network infrastructure. The Internet’s security shouldn’t be upheld by a handful of volunteers who find their names in the news only when something goes wrong.
