Heartbleed And The Curse Of Third-Party Code

The recently disclosed vulnerability in OpenSSL pokes a number of enterprise pain points. Chief among them: the proliferation of vulnerable, third-party code.

heartbleed

By now, a lot has been written about Heartbleed (heartbleed.com), the gaping hole in OpenSSL that laid bare the security of hundreds of thousands of web sites and web based applications globally.

Heartbleed is best understood as a really, nasty coding error in a feature that was added to a ‘heartbeat’ feature that was added to OpenSSL in March 2012. The heartbeat was designed to prevent OpenSSL connections from timing out – a common problem with always-on Web applications that was impacting the performance of those applications.

If you haven’t read about Heartbleed, there are some great write-ups available. I’ve covered the problem here. And, if you so inclined, there’s a blow-by-blow analysis of the code underlying the Heartbleed flaw here and here. Are you wondering if your web site or web-based application is vulnerable to Heartbleed vulnerability? Try this site: http://filippo.io/Heartbleed.

This one hurts – there’s no question about it. As the firm IOActive notes, it exposes private encryption keys, allowing encrypted SSL sessions to be revealed. But it also appears to leave data such as user sessions subject to hijacking, and exposes encrypted search queries and passwords used to access major online services– at least until those services are patched. And, because the vulnerable version of OpenSSL has circulated for over two years, it’s apparent that many of these services and the data that traverses them has been vulnerable to snooping.

But Heartbleed hurts for other reasons. Notably: it’s a plain reminder of the extent to which modern, IT infrastructure has become dependent on the integrity of third-party code that too often proves to be unreliable. In fact, Heartbleed and OpenSSL may end up being the poster child for third-party code audits.

First, the programming error in question was a head-slapper, Johannes Ullrich of the SANS Internet Storm Center told me. Specifically, the TLS heartbeat extension that was added is missing a bounds check when handling requests. The flaw means that TLS heartbeat requests can be used to retrieve up to 64K of memory on the machine running OpenSSL to a connected client or server.

Second: OpenSSL’s use is so pervasive that even OpenSSL.org, which maintains the software, can’t say for sure where it’s being used. But Ullrich says the list is a long one, and includes ubiquitous tools like OpenVPN, countless mailservers that use SSL, client software including web browsers on PCs and even Android mobile devices.

We’ve talked about the difficulty of securing third-party code before – and often. In our Talking Code video series, Veracode CTO Chris Wysopal said that organizations need to work with their software suppliers – whether they are commercial or open source groups. “The best thing to do is to tell them what issues you found. Ask them questions about their process.”

Josh Corman, now of the firm Sonatype, has called the use and reuse of open source code like OpenSSL a ‘force multiplier’ for vulnerabilities – meaning the impact of any exploitable vulnerability in the platform grows with the popularity of that software.

For firms that want to know not “am I exposed?” (you are) but “how am I exposed?” to problems like Heartbleed, there aren’t easy answers.

Veracode has introduced a couple products and services to address the kinds of problems raised by Heartbleed. Today, customers can take advantage of a couple services that make response and recovery easier.

Services like the Software Composition Analysis can find vulnerable, third-party components in an application portfolio. Knowing what components you have in advance makes the job of patching and recovering that much easier.

Also, the Web Application Perimeter Monitoring service will identify public-facing application servers operating in your environment. It’s strange to say: but many organizations don’t have a clear idea of how many public facing applications they even have, or who is responsible for their management.

Beyond that, some important groups are starting to take notice. The latest OWASP Top 10 added the use of “known vulnerable components” to the list of security issues that most hamper web applications. And, in November, the FS-ISAC added audits of third-party code to their list of recommendations for vendor governance programs.

Fixing Heartbleed will, as its name suggests, be messy and take years. But it will be worthwhile if Heartbleed’s heartburn serves as a wake-up call to organizations to pay more attention to the third-party components at use within their IT environments.

Anonymous | April 20, 2014 3:49 pm

On a regular basis, developers threaten to take their ball home and not play if everyone doesn’t kiss their asses. The developers who introduced this nightmare screw up will not be punished more than having to take a little extra training. What a racket.

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

*

RSS feed for comments on this post