Jack Wallen offers his reaction to the tragic Heartbleed bug and suggests the solution is more challenging than one might assume.
Heartbleed. This single word instills fear in the minds and hearts of system administrators around the world -- for the moment. Give it a while, and that word will be replaced by yet another... and another... and another. That is the new reality.
We live in a world where it's only just a matter of time before the next big catastrophe sweeps through and whisks our data into the hands of nefarious ne're do wells. Black Hat hackers tirelessly pour over code -- new and old -- to find flaws, holes, and bugs they can exploit. And boy, do they exploit!
This time around, it's SSL -- or, rather, OpenSSL. What has been dubbed the Heartbleed bug, when exploited, "bleeds" random data from memory. With this, you never know what you'll get. It's like a one-armed bandit handing out either a disappointment or a jackpot. If you hit the jackpot, you could have your hands on credit card information, social security numbers, names, addresses -- the list goes on and on.
But how did it happen? Was this nothing but laziness or poor coding on the part of the OpenSSL developers? Was it an inside job? A trojan horse inserted into the code, years ago, waiting for the right time and place to leap into action?
No. It was an inevitability. No matter the platform, flaws and exploits will be found. That's one of the realities we face.
Since the dawn of mankind, there has existed a dichotomy of those who give and those who take, those who fix and those who break. Bank robbers have forever plotted and schemed for the perfect heist. Art thieves have gone to extensive means to lift our precious treasures. With our world and systems ever more digitally dependant, hackers will do what they do best -- comb through code to find possible flaws.
Of course, saying "It's just the way it is," sounds defeatist -- as in, we may as well just sit back and let the Black Hat hackers have their way. That's not gonna happen. But what can we do? Let's think about it...
- You create a piece of code that works flawlessly
- You release the code
- The code is used, without incident, for years
- Eventually someone discovers a weakness
- That weakness is exploited
- Innocent people lose data or money
You didn't plan this. Even though you did extensive debugging of the code, you saw nothing wrong. The thing is, time and tide is ever changing. This means your code could be implemented in a way that it wasn't meant. Or maybe another piece of a larger puzzle evolved that lead to a flaw in your code. Either way... it will happen.
The crucial element is how to respond. The logical answer?
- Alert users of the flaw
- Locate the flawed code
- Patch the flawed code
- Test the new code
- Release the patched code
Notice the first point -- alert users. That's right, I said it. Alert the users. It's important to have a level of culpability and transparency. Obfuscating this from users could only lead to finger-pointing, and that's the last thing you need. Be up front.
Ultimately, there's something seriously missing. There exists various consortiums (such as ISC -- Internet System Consortium and the Web Application Security Consortium) whose purpose is to keep on top of such issues as security flaws and breeches. However, so many of them have their own agenda: they push a particular piece of software, and sell a brand of hardware. And, of course, there's the NSA...
When such a tragic flaw like Heartbleed is discovered, it's reported to the public via news, social media, and word of mouth. Most often, the effects of these flaws are overly exaggerated or simply incorrect (unfortunately, in the case of Heartbleed, the exaggerations were fairly accurate and spot on).
What I would suggest is that, from the open-source community, a new consortium is developed whose sole purpose is to disseminate the truth about found flaws and bugs in systems that affect day-to-day life, a central repository where people can turn to discover what exactly is happening at that moment and to help alleviate the problems.
As mankind continues to depend more on mobile devices, wireless (and wired) payment systems, and online identity, the hacks, flaws, bugs, and exploits are only going to continue to intensify. We need a central organization, sans self-serving agenda, that the public can turn to in order to get the most accurate, up-to-date information on such nasty flaws as Heartbleed.
I'm fairly confident that Heartbleed will not be the last game-changing flaw found in any system. So long as servers are connected to the internet, exploits will be found. Not only do these exploits need to be patched immediately, information about the flaws needs to spread (from a centralized location) so that everyone is made aware and can learn how to quickly keep from losing sensitive data.
Winning this war is not an option. The second you think you've won, you'll find you're back on the losing side. Black Hat hackers will always find a way to exploit and take. They yang our yin, black our white, and will always be there... searching for the next hole to jump through. It's impossible to predict every factor that goes into an exploit of code. It is possible, however, to inform. Unfortunately, this type of transparency isn't quite as prevalent as it should be. Take, for instance, the OpenSSL website. Here is the information they have on Heartbleed:
A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.
Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.
Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley <email@example.com> and Bodo Moeller <firstname.lastname@example.org> for preparing the fix.
Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.
1.0.2 will be fixed in 1.0.2-beta2.
No major announcement on the front page of the website. Nothing. Do a Google search for heartbleed and you'll be presented with more information than you can consume in a day (or a lifetime). So, why is the OpenSSL site so lacking?
Three words that should serve as a guiding force when it comes to flaws like Heartbleed and those responsible for patching the affected software.
Don't get me wrong, I'm not (in any way) tossing a blanket of blame over OpenSSL. They should have more immediate information on the flaw, but they can't be blamed for Heartbleed... just like the next innocent group of developers can't be blamed for the next major exploit.
Because this war will never end, it's time to come up with the means to form a more perfect union that can help spread correct information, patches, and help predict tragic flaws in the software we dependent on.
Is this possible? Or am I missing something and there's already a consortium developed just for this purpose? Share your thoughts in the discussion thread below.