HeartBleed: OpenSSL is free software? That's lucky!
Sadly now known as HeartBleed, a vulnerability in OpenSSL has been discovered this Monday, April 7, 2014.
It potentially exposed all encrypted communications (webmail, online shopping, banking ...) since 2 years and allowed their potential decryption.
Because OpenSSL is free software, this vulnerability could have been effectively managed, from a purely source-code side as well as a deployment side and community involvement.
HeartBleed, all naked on the Internet
SSL/TLS, the basis of encrypted communication, not that well encrypted, in fact
Sometimes, as you browse the Internet, and perhaps without even knowing, you use secure connections. These are actually encrypted connections. This occurs when you connect to your favorite webmail or online bank. The need for such security is obviously understandable. Absent this, and your data flows unencrypted between your computer and the server, making it very easy to read your email address, password, or banking details. This way, a government agency, or a malicious individual who may be watching the traffic between you and the server, can access the content of your messages.
Most of the secure servers use the HTTPS protocol. When you connect to such a site, a padlock appears in the URL bar. The software behind such encrypted communications is most of the time the free program OpenSSL. Recently, a vulnerability was unveiled by computer security researchers in the OpenSSL library. Its name is: HeartBleed.
This vulnerability was introduced wo years ago and exposed the content of the server's memory. Anybody has had access to the confidential data of affected servers since that date. This flaw strictly leaves no evidence of compromission if exploited, so we must assume that any affected machine has been compromised, user data leaked and private keys stolen.
There is an extremely annoying point if we remember the NSA/Prism case. The NSA stores all the communications they spy on, including SSL/TLS-encrypted content (website browsing sessions, email exchanges, Jabber conversations, etc.), in the hope of deciphering them at a later date, by taking advantage of a disclosed vulnerability or increased technological capabilities, by bruteforce attack, etc. So the NSA had the possibility to steal some private keys on compromised servers, and decipher all the theoretically securised communications that had taken place in the past and were stored for later decryption.
Decryption is possible for all the messages which have been encrypted by the corresponding private key, and is therefore not limited to the lifetime of the SSL certificate (usually one year) which was actually used at the time of the HeartBleed flaw exploitation. If the online service in question has constantly used the same private key for decades, these are years for which the security of communications has vanished.
The only servers which were able to avoid the HeartBleed problem are obviously those which were not subject to the flaw, and those which were using PFS (Perfect Forward Secrecy). These are unfortunately still too rare, less than 3% of servers.
Role of free software in the handling of HeartBleed
What can we learn from this? A hasty analysis may lead some people to say that HeartBleed is a disaster for free software. But having a free and open code, however, significantly reduced the impact of this flaw. Even though the impact can be potentially huge, nobody ever said that free software is always bugproof! Now, imagine for a moment that such a fault had affected a proprietary software package…
The four freedoms, direct access to a patch
People who find an abnormal behavior (here, access to a theoretically inaccessible memory area), being unable to read the source code, can't understand the actual origin of the problem (here, a missing bound-check). In the case of HeartBleed, it was the very reading of the source code, with the intention to add new features, which allowed detection of the flaw. Then, the fix was immediately provided by and to the community, because once again the source code was made available. This couldn't have been be done so easily with proprietary software, since the patch could be made only by the entity in charge of the code.
Worse, it's very likely that such vulnerabilities exist in proprietary software… And nobody is aware of them, because the information doesn't exit the company's walls, and moreover the company doesn't want to correct them for various reasons: damage to its reputation, low priority assigned to the corrective action (especially if the fault was not massively disclosed to users), understaffing (the staff being assigned to higher priority projects), or willful introduction of the vulnerability upon request by a governmental entity.
Free software, distributed but organised
Deployment of the fix was very fast, too, with patches available within a few hours of disclosure for most GNU/Linux and BSD distributions. Package managers 1 greatly facilitate the work, which would not have been as straightworward and effective on Microsoft Windows, for example, since it doesn't have a centralised software center and can correct only its own operating system and software, but not user-installed third-party software.
“Community”, I Write Your Name 2
Recent cases in the proprietary world also show that, however profitable a company is, and whatever the technical quality of its staff, it remains vulnerable. It's only the alertness of the community which enables such loopholes to be found.
Thus, Apple has officially thanked hackers of the iOS7 jailbreak for allowing them to detect a security breach they had left in the code. Of course, these thanks were tainted with sarcasm, but it shows the inefficiency of the proprietary model at discovering flaws. Others flaws were found in proprietary systems, including one discovered by a 5-years-old.
After all, finding and fixing bugs is routine in the computer world. Yet, free software has a definite advantage in this respect: it allows access to the complete source code, by anyone and for any use, meaning that we can all participate in this bug hunting, we can all immediately correct any flaw we find for our own use and share this fix with the rest of the community.
Further analysis of the HeartBleed incident shows that the management of this issue, in fact, proves the efficiency of free software: the breach was corrected within 24 hours on dozens of distributions and different architectures, very simply in most cases! Such responsiveness in the correction of security problems is specific to free software, because its community organisation and its access to source code allow the collaborative work of hundreds of developers within a very short time.