Heartbleed Postmortem: Time to Rethink Open Source Security?

April 15, 2014 Alex Woodie

If you feel sick to your stomach from the Heartbleed OpenSSL bug, you’re not alone. The retailer Target may have lost data on 100 million customers, but that’s nothing compared to the billions of supposedly secure online transactions conducted across millions of websites over the past two years that we now know were potentially exposed and could be fodder for hackers. For IBM i customers, who have basked in the shadowy protection that IBM‘s (mostly) proprietary architecture has afforded them for decades, the question becomes: Can we trust open source to protect us?

The good news is that it appears the Heartbleed bug had a limited direct impact on the IBM i platform. While IBM does offer OpenSSL as part of a free utility that runs via PASE, it used an older version of the OpenSSL library (version 0.98) that was not susceptible to the bug. As IBM i security expert Patrick Townsend explains, the guts of IBM i do not rely on open source encryption technology.

“The first important fact to know is that OpenSSL is not commonly used in traditional IBM i network applications,” Townsend tells IT Jungle via email “IBM has an SSL/TLS library named GSKit and a certificate management application named Digital Certificate Manager. The underlying secure TLS implementation is not based on OpenSSL for these IBM-supplied applications. They probably do not pose a security issue for IBM i customers.”

Most third-party vendors in the space use the IBM i SSL/TLS library for secure communications and therefore are not vulnerable to the Heartbleed vulnerability, Townsend says. This includes most of the Townsend Security applications, including the Alliance AES Encryption for IBM i offering, which brings NIST-certified encryption capabilities to the DB2 for i database. The company’s Alliance Key Manager does use OpenSSL, Townsend confirmed. But it doesn’t use an affected version, and while it often connects to IBM i servers, it does not run on IBM i directly.

This goes to one of the core tenets of security in a connected world: While a vulnerable product may not run directly on IBM i (or any other server platform), it doesn’t have to run there to create havoc with applications running on IBM i (or any other server platform). We live in an inter-connected world, and security problems have a nasty habit of escaping beyond the firewalls we put in place.

For example, Cisco confirmed that its networking gear is susceptible to the Heartbleed problem. Don’t run any Cisco gear in your shop? It doesn’t really matter, because much of the world does.

“It is important to understand that while the IBM i platform may not be directly vulnerable to the Heartbleed problem, you may have lost IBM i user IDs and passwords over VPN or other connections which are vulnerable,” Townsend says. “An exploit of Heartbleed can expose any information that you thought was being protected with session encryption.”

If you feel like you have a craw in your throat, you’re not alone. Heartbleed is arguably the biggest security vulnerability in at least a decade. All the trust in network communication that we have gained since the dark days of weekly Patch Tuesday revelations of security horrors are coming back to us.

So, what do you do? For starters, change all of your IBM i passwords, especially the passwords for powerful users and administrators. The chance that password for somebody with QSECOFR privileges is sitting in plain text in some hacker’s data mart, waiting to be dug up and exploited, is too great to ignore.

In the long run, the question is not so simple. The open source method of developing, testing, debugging, and supporting software has become commonplace over the past 10 years. We take open source products for granted, and they have mostly served us well.

For Patrick Botz, the former AS/400 security architect for IBM and now the president of biometric authentication technology provider Valid Technologies, the Heartbleed issue raises questions about open source’s role in software development.

“I am a believer in open source,” Botz tells IT Jungle via email. “But I have never believed that open source code is ‘more secure’ than proprietary code simply because it is open source. This incident proves that good actors [even large numbers of them] can [and do] miss security bugs.”

Botz says he is particularly concerned about the revelations that the National Security Agency (NSA) exploited the Heartbleed vulnerability to conduct surveillance on people. “Coupled with the NSA stuff, it seems reasonable to me that bad actors can introduce security bugs in code that can be missed by good actors eyeballing that code,” he says. “If one good thing comes out of this, perhaps we will hear less of the ‘open source is better for security’ arguments that have been fairly prevalent.”

That doesn’t mean that proprietary code is inherently more secure than open source either, Botz adds. IBM i shops may be used to run proprietary code, but it’s tough to completely avoid all open source code. On the IBM i server, we’ve seen everything from anti-virus and programming languages to CMS and ETL systems developed in the open source manner. You can’t judge all of open source from one bad episode.

In any event, bad code can be written any number of ways. The fact that IBM used its own internally derived SSL layer in its core ILE products shows you that having a trusted and experienced partner and software provider is perhaps more critical than we may have believed two weeks ago.