The recently discovered flaw in OpenSSL sent shockwaves through the security industry, as the widely used library rendered thousands of systems vulnerable to attack.
Apr 20th, 2014
The recently announced Heartbleed vulnerability has shaken the security world to its roots. [Before further discussion, let me point out that neither Globalscape’s EFT platform, CuteFTP, nor Tappin products are vulnerable to the Heartbleed bug. Mail Express does have certain configurations that are vulnerable, as documented here, but appropriate remediation has been provided.]
This error in the wildly popular OpenSSL package might seem like it is overpublicized, but it is not: this is a fatally serious flaw in one of the most fundamental elements of security. Every human on the planet using the Internet to transact business is affected by OpenSSL. For more than two years, this easily exploitable, high-risk vulnerability has been running unnoticed in over half a million web sites. It is bad enough when confidential information like credit card numbers is exposed in a breach. However, the magnitude and potential for wrongdoing as an effect of this vulnerability is hard to imagine. When Heartbleed left private keys to SSL certificates vulnerable, all of the SSL encrypted traffic on secure sites became susceptible to attacks on many of the most popular sites in the world. Worse yet, this vulnerability made it possible for attackers to spoof sites and trick users into giving up valuable information. This was all done in a way that was both easy for the attacker and almost impossible for the victim server to detect.
Think about that for a second: if your bank had been compromised at any point in the last two years, your sensitive information might have been compromised. Fraudsters might have even impersonated your bank to solicit information directly from you, with neither you nor the bank being the wiser. Both are scary thoughts.
This is a fundamental, dangerous, horrible flaw in SSL. It undermines our long established trust in the security of our confidential information flowing across the internet, and rightly so. We have all been trained that the little lock icon in our browser means that transactions are safe. I have taught that to my mother, to my non-technical friends, and to my children. Most internet users put their trust in SSL as a secure protocol, and many geeks, like me, put our trust in the open source OpenSSL Project. After all, an open source project means that multitudes of smart people are reviewing code and preventing serious errors like this, right? Furthermore, let's not forget that OpenSSL has a NIST certificate for FIPS 140-1 validation. Doesn't this mean that we can rely upon it for security? What about all of the security audits ("pen tests") performed by reputable companies that help to ensure safety of systems—surely they would confirm proper operation of SSL-enabled systems and provide reliable security?
In truth, no. This illustrates one of the fundamental challenges of trust, which is shown in full relief through the OpenSSL Heartbleed vulnerability but, in fact, is a pervasive challenge for all computing. The NIST certification pertains to the cryptographic algorithms contained within OpenSSL libraries, not the implementation of the SSL (or TLS) protocols, which use those cryptographic primitives. Security audits typically look for specific known vulnerabilities, and rarely find weaknesses that are not widely known. Obviously, if the Heartbleed bug has been in the wild for more than two years on hundreds of thousands of web servers—not to mention email servers, embedded systems, and other systems—security assessment firms failed to identify a serious flaw. Without the ability to rely upon neutral, impartial third parties to verify the trustworthiness of highly complex security systems, we all stand in the shadow of Heartbleed with a new and deserved skepticism of the security, which we had previously taken for granted.
As an engineer, I’ve tried to make sense of the intention of the code. The fact that the Heartbleed vulnerability is based upon obtaining random tailings of heap memory contradicts secure coding practices; memory should be initialized when allocated and sanitized when finished. The only advantage of this practice is increased performance. I will save further technical details for a subsequent post, but I have some Globalscape engineers working on performance analysis of using an initializing memory allocator for security of OpenSSL (calloc, for example) versus the standard non-initializing one (malloc). Though I can understand the arguments that one is faster than the other, it begs the question whether speed is more important than security. Our addiction to instant response times for all things technical places great pressure on the security industry. For one, I would rather have had a fraction of a second more time on a memory allocation than 2 years of an easily exploitable bug that renders SSL security untrustworthy.
Globalscape will continue to pursue software development with security at the forefront of our mind, using Heartbleed as a stark reminder to be vigilant in the trust we place in the security of third-party resources. We have always maintained high standards in our secure software development lifecycle, relying upon thorough testing as well as in-house and external security expertise, and will continue to do so; not as a reaction to Heartbleed, but as a continued part of our guiding principles. We hope that all other stewards of information security will do the same.