Ages ago, man invented the wheel. Some say this occurred around the second half of the fourth millennium BC. Since then, no one has needed to “reinvent” the wheel, just use it and improve on it.

In many ways, software such as OpenSSL is like the wheel. Once a problem has been defined and a software solution is coded, debugged and tested, if it has been designed to be reusable, other applications can take advantage of the finished product. This reusable code is placed into “libraries” to make it easier to incorporate into other applications. Today’s open-source world has a large number of libraries available for use to make communications easier, file transfer possible and expedite a number of other functions.

OpenSSL is one such library available to enable an application to communicate via Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. OpenSSL is based on an earlier library, SSLeay, developed by Eric A. Young and Tim J. Hudson. The software is freely available for use through the Apache-style license and can be used for personal or commercial purposes.

As with any production-ready software package, OpenSSL was generally considered to be reliable. Created in 1988 as a library that offered a number of generic encryption/decryption subroutines, OpenSSL has been incorporated and used in a number of different applications, such as Web servers, virtual private networks (VPNs), tunneling applications, network file shares (NFSs), Java, Samba, SMTP servers, domain names servers (BIND) and others. In other words, for applications that need to communicate securely, it is more cost-effective for a company to use an existing, tried-and-true library than create their own from scratch.

The Heartbleed Debacle

That is, until something like Heartbleed is discovered. The vulnerability, identified as CVE-2014-0160, can result in the leaking of memory due to a bug in the way OpenSSL handles the TLS/DTLS heartbeat extension (RFC6520). This extension provides the ability to perform a “keep-alive functionality without performing a renegotiation.”

The original intent of the code was to allow a client (browser) to verify that the server was still present and available for requests. The client sends a packet to the server containing data and a size, supposedly, of the data being sent. The server takes that data and the size specified and returns a packet containing the dump of memory from the location it stored the incoming data for a period specified by the “size.” In a normal situation, the client might send “foxtrot” and the size “7” and that is what the client would receive back from the server.

The Heartbleed incident exposed two issues: One, that a client did not need to have a prior connection to the server to be able to make a “heartbeat request,” and two, that the client did not have to be truthful when specifying the size of the data it wanted returned.

This allowed an attacker, who had not entered into a prior session with the server, to send a heartbeat request to the server with “foxtrot” but specify that the size was up to 64K instead of only 7 bytes. Depending on where the server stored the incoming data (i.e., “foxtrot”), the server would start there and begin sending data until the specified size had been sent. Since the storage of the incoming data might coexist with memory used to decrypt the server’s private key, users’ passwords or other confidential data, this vulnerability represents a huge leak of potentially sensitive information. And because the attacker would not know where his data was stored nor potentially what might be stored in memory next, this attack might have to be carried out multiple times before any useful information was retrieved.

In the early days of Heartbleed, CloudFlare issued a challenge to see if it was even possible to retrieve sensitive information using this method. Within nine hours of the challenge, two individuals returned the private SSL key of the server to CloudFlare. One individual required approximately 2.5 million requests, and the other only sent in approximately 100,000 requests. Both individuals had returned the correct private key and had also demonstrated the randomness of the location data stored in memory on the server.

OpenSSL Under Renewed Attack

Just when the Internet community was beginning to solve all of the issues from the Heartbleed incident, a new vulnerability, CVE-2014-0224, has been discovered. This vulnerability, a Man-in-the-Middle (MitM) attack, may be difficult to exploit. It requires that both the server and the client be vulnerable and that the attacker be able to intercept and change the packets while they are en route to their destination. It requires that the attacker detect a new TLS connection and wait until after the ClientHello/ServerHello handshake messages are sent. The attacker would then send a Change CipherSpec (CCS) packet to both the client and the server. This request signifies that all future communication will be sent under a new CipherSpec and keys. This causes the OpenSSL code to generate a new secret key of length zero or, in other words, no secret key. The client and server then renegotiate the handshake parameters, and the attacker is able to decrypt or modify any future transactions.

A decade ago, such an attack might only have been possible if the attacker was located on the client’s or server’s network or located at an Internet service provider (ISP) between the client and server. Now, with the proliferation of available wireless access points, such an attack becomes even more possible. This would require that the attacker either have control over such a public access point or set up his own to lure victims.

No software package is considered bug-free, but OpenSSL’s 16 years of service does speak highly of the software. After the Heartbleed incident, the OpenSSL developers appealed to the Internet for assistance. As a volunteer project, resources were limited. As a result, a Linux Foundation project was created that promised to fund a security audit of the OpenSSL code base. In addition, the project would also fund the salaries of two full-time developers dedicated to the OpenSSL project. IBM is one of the major vendors involved in supporting this project.

The use of open-source projects, such as OpenSSL, means that companies can save development costs by not having to “reinvent” the wheel, as it were. It also means that they can take advantage of the years of code testing through its use in other products. And once in a while, maybe twice, it may mean an industry-wide scramble when that code does develop issues.