The Heartbleed Lesson: Open Source Needs Attention

wayne Rash

Heartbleed happened because web giants thought that open source provided them with a free ride, says Wayne Rash

Every day brings new reports of the threats posed by the Heartbleed bug. But the discovery of Heartbleed has also unearthed a scandal that’s plagued the open-source community for years.

The scandal is that giant enterprises are doing nothing to contribute to the development, testing and validation of the free software on which they depend. They are takers, pure and simple.

jheartbleed security, latch chain link door  © Sergios Shutterstock

Adding a heartbeat function

Nothing makes this more obvious than the details revealed by the German developer who was responsible for the bug in the first place, Dr. Robin Seggelmann.

Dr. Seggelmann, it appears, was spending his end-of-the-year holiday working to fix bugs in the first version of OpenSSL, the encryption software that was becoming a standard on the Internet. While he was at it, Seggelmann developed a way to create a heartbeat function that could keep encrypted sessions open rather than timing out over time.

The idea of a heartbeat in this sense is to confirm to the computer at the remote end of the session that the link is still active, reducing the need to log off and then re-establish an encrypted session to transfer more data. By doing so, he created a way to dramatically reduce latency in these connections by eliminating the hand-shake delay. It was a very good idea.

But as happens so often in development, Dr. Seggelmann made a mistake. He forgot to indicate an end variable, which in turn could cause a buffer overflow, which in turn could reveal up to 64 kilobytes of data in the memory of the server at the remote end. This mistake wasn’t caught at the time and eventually ended up in the production code.

So why wasn’t the error caught? There’s been a lot of speculation in the blogosphere about this, with some suggesting that it was an Evil Plot by the National Security Agency. Others suggested that the developer was incompetent. In reality, neither is true. It was a coding error, pure and simple. It wasn’t caught because there are only a handful of people in the entire world working, for free, to develop OpenSSL.

The problem is we assume people are watching

And that idea of an open, free software development environment in which an entire community of programmers work together to create software everyone needs is part of the problem in this case. It’s a problem because it assumes that there will be a large community of developers, all of whom check the code over time, looking for errors.

But in the real world, the open-source software is developed and then released into production, and because there are so few people in the community who understand it, very little checking happens.

What checking that does happen can take years. That’s what happened with OpenSSL, and is the cause of the Heartbleed bug.

The obvious question here is, Why does something as critical to the safety of the Internet as OpenSSL get so little attention? The answer is equally obvious—money. Those large companies that use OpenSSL for their business haven’t been contributing anything to its development. In fact, the few thousand dollars the OpenSSL project got last year came from individual donors worried about spying.

What’s worse, this problem with open source is no secret, as is detailed by USA Today and Yahoo Tech columnist Rob Pegoraro in his blog. What it boils down to is that everybody just assumes that open source is magically validated and must be OK. Unfortunately, sometimes it’s not. It’s the nature of such community development projects that sometimes big problems get missed, as Craig Timberg explains in The Washington Post.

But rather than use the Heartbleed bug as a reason to indict open source as being unreliable, what really needs to happen is to use this as a wakeup call. All of those companies—from Yahoo to Dropbox—that used OpenSSL without doing anything to help create and improve the product are paying for that neglect now. Once they spend millions to fix the problem, perhaps they can spend a few thousand more to help fund development of this critical security library.

Ultimately, the projects that come out of the open-source communities are excellent products, but to achieve excellence, they need more resources than they are getting. The people who donate their time and talent to create critical products such as OpenSSL have rent to pay, food to buy and families to support. They may want to spend their lives creating excellent software, but they can’t without help.

But there’s no reason why Google, Yahoo and others can’t contribute to development. Sure, the code might be free, but it’s not without cost. The companies that have been using the code for free and benefiting from it are now discovering the true cost of free, open-source software.

But there is more than one way to pay for free software. You can pay a little up front to help make sure it’s done right, is tested thoroughly and is stable, or you can pay a lot more later when you find out that it’s none of those things. Now that these companies have discovered that higher cost of paying later, maybe they can save money in the long run by paying a little bit forward.

What’s in a name?

Originally published on eWeek.