Heartbleed

On Monday, April 7, 2014, a four-byte flaw in the widely used OpenSSL encryption library was made public.  The bug, dubbed Heartbleed, lies within the OpenSSL implementation of the TLS heartbeat extension and may allow the extraction of sensitive in-memory data (login cookies, passwords, crypto-keys) from systems that rely on OpenSSL versions 1.0.1 and 1.0.1f. 

OpenSSL provides a secure line for Internet communications and encrypts data so it can be decrypted only by the intended recipient.  Sometimes this requires one of the communicating computers to confirm that there is still a computer on the other end, and it will send a small packet of data known as “heartbeat.”  The code flaw allows a packet of data disguised as “heartbeat” to trick the receiving computer into sending back data stored in its memory, 64 bytes at a time.   

The Heartbleed bug compromised the security of websites, client software, email servers, and chat services.   Many popular web services have been patched following the disclosure of the security vulnerability, and a new version, OpenSSL v. 1.0.1g, has been released.  

The implications for this incident on open source software center on an old debate as to whether open source is likely to be more secure than proprietary code.  Despite the widespread use of OpenSSL, the core development team for the project consists of only four volunteers and is minimally funded by donations and sponsorships.  The open source mantra that “given enough eyeballs, all bugs are shallow” may fail when a project is not well supported by the communities that use it.  The faulty code containing Heartbleed bug was written by a contributor who did not notice the mistake, and the bug was committed by one of the core developers, causing speculation that the bug slipped through because the core team was spread too thin. 

The “debate” over whether open source or proprietary code is more secure is, of course, a red herring: there is no one answer.  Open source advocates often point out that proprietary code can be more vulnerable to the extent it relies on “security by obscurity,” and relies on a single vendor to correct flaws.  However, proprietary software champions claim that open source code may be more likely to suffer from inadequate quality control if it is not properly supported, because no one vendor has the economic incentive to provide support.  This debate will, of course, never be resolved.  But the Heartbleed incident is certainly a wake-up call, and a reminder that any company using software has to know where its support is coming from — whether that be the community or a private source.