Serious question: Who should pay for Heartbleed?

[Update 4/23/2014: After this article was published, a report surfaced that Google, not Codenomicon, may have been primarily responsible for the pre-release of the Heartbleed vulnerability. Codenomicon has also contacted me directly, saying it did not reveal Heartbleed to anyone other than NCSC-FI  prior to April 7. Given these developments, I no longer believe it’s accurate to say Codenomicon or NCSC-FI were primarily responsible.]

The discovery and disclosure of CVE-2014-0160, better known as Heartbleed, as it was nicknamed by security firm Codenomicon, came about in a very unusual manner.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":1451422,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,cloud,dev,enterprise,security,","session":"D"}']

Security professionals have a process for handling vulnerabilities. It entails communication about the discovery with the team responsible for the potentially vulnerable software, which prompts that team to patch the vulnerability, release an update, and disclose details to users.

Responsible users will update their software to limit their exposure, while the development team works with an authority like Carnegie Mellon’s computer emergency response team coordination center (CERT/CC) to release details.

That’s how it’s supposed to work. But it’s not what happened with Heartbleed.

What went wrong?

Here’s how Heartbleed went public:

• On March 21, Googler Neel Mehta discovered Heartbleed. Google engineers wrote a patch to guarantee Google’s security. That wasn’t communicated to the OpenSSL Project, which was responsible for maintaining the once-vulnerable software until April 1.
• On April 2, Codenomicon discovered Heartbleed, which was a problem, as OpenSSL didn’t plan to release details of the vulnerability until April 9.
• That week, either Codenomicon or the National Cyber Security Centre Finland (NSCS-FI) allegedly began disclosing Heartbleed’s existence to vendors like CloudFlare, Akamai, and potentially others, providing a strategic advantage in defeating the vulnerability, while larger companies like Yahoo, Juniper, and Cisco were left in the dark. CloudFlare bragged about receiving news of the vulnerability a week early. Akamai claims to have been notified by OpenSSL, which the OpenSSL Project denies.
• On April 7, NCSC-FI notified the OpenSSL Project of a second discovery. Fearing Heartbleed news had already leaked, the OpenSSL Project released 1.0.1g two days early, spreading panic across the information-security community.

So, who will pay for the damage?

One might assume Robin Seggelmann, the programmer taking responsibility for the bug, or the OpenSSL Project are liable for Heartbleed. But the problem is more complex. The software is open source, meaning it’s free for anyone to use or modify, and it includes disclaimers for nearly every type of liability imaginable. Even if OpenSSL or its contributors were liable, there are no deep pockets to fall back on. Everyone working on it is a volunteer. Who is left to make reparations?

The case for commercial software

Heartbleed could cause, or might already have caused, catastrophic damage. Even without a confirmed breach, fixing it could cost billions. Additionally, customers of affected companies might say a company’s use of open-source software placed them at risk, and those customers might demand compensation. That’s motivated some companies to rebuff the open-source movement in favor of established software companies that can pay damages and be held accountable for vulnerabilities.

Open-source proponents, including me, scoff at that idea. Aside from being free, open-source software provides tremendous benefits over commercial alternatives. For years, some of the brightest minds in programming have contributed high-quality updates to open-source projects in a timely manner and provided fixes for vulnerabilities hours or minutes after discovery, preventing wide-scale exploitation. These projects are critical to the operation of the Internet.

Where does this leave us?

It’s strange that two parties found a bug simultaneously after it had existed for over two years. If it had been handled responsibly between Google and the OpenSSL Project, the vulnerability would have been patched, and OpenSSL 1.0.1g would have been released without incident. While it would still be necessary to update servers, change passwords, and revoke SSL certificates, it’s unlikely that Heartbleed would have caused the pandemonium that occurred because of Codenomicon’s involvement. Many people don’t know that CERT/CC has published at least 10 vulnerabilities since Heartbleed. Vulnerabilities happen. The key to minimizing the degree of exposure is how quickly and transparently they’re handled.

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":1451422,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,cloud,dev,enterprise,security,","session":"D"}']

The reason Heartbleed caused such panic wasn’t related to the open-source community, but, rather, Codenomicon’s discovery of the vulnerability while Google, the OpenSSL Project, and other responsible parties attempted to coordinate a response. That resulted in Heartbleed’s commercialization.

Codenomicon and the companies it allegedly notified were able to report how their companies discovered Heartbleed before the CVE publication and used that opportunity to prepare themselves for its release and keep customers safe. In fact, Codenomicon coined Heartbleed when it registered heartbleed.com to publicize news of its discovery.

What’s even more unusual than two companies discovering a vulnerability concurrently is that one would privately disseminate news of it without first coordinating with the cognizant open-source project. Notwithstanding such an anomaly, open-source programs work and can be relied on to release high-quality software, fix bugs, and patch vulnerabilities in a responsible manner that doesn’t place the public at risk.

Jeffrey Lyon, CISSP-ISSMP, is the founder of Black Lotus Communications, a DDoS mitigation firm focusing on solutions for service providers and enterprises. He can be followed on Twitter at @ddosguru.

[aditude-amp id="medium2" targeting='{"env":"staging","page_type":"article","post_id":1451422,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,cloud,dev,enterprise,security,","session":"D"}']