The Heartbleed vulnerability is just mindboggling in scope. The culprit(*) is hiding in a library called “openssl”; It’s a handy little library that makes it a lot easier for a programmer to do SSL, and everybody is using it. The reason is that SSL is very complex; writing an SSL module from scratch would take ages, and be extremely error prone. So instead we piggyback off of what others have done, and save a lot of time and effort.
In the development community, there’s a general consensus that “rolling your own XYZ” when there’s already a well-tested XYZ available, is a pretty bad idea. But there are still some developers to want to write their own stuff, and scoff at anything not written by themselves. Almost all developers have, at one time or another, been seduced by a promising library, only to discover that said library had a fatal flaw that you just couldn’t fix. So it’s always a balancing act – I feel a little uneasy every single time someone adds a new 3rd party library to our app. Mainly because I have no control over the quality of that module – perhaps it leaks memory, perhaps it crashes, and if it does, it’s my responsibility to come up with a solution(**). Only problem is – I may not have access to the source code of the module, and thus I simply have to relay the bug to the 3rd party, who may or may not appreciate the gravity of the situation. So, depending on the complexity, I’m one of those that roll my own more frequently than I probably should.
The problem with Heartbleed goes beyond just your server. A great many number of client apps are using openssl, and thus they may be susceptible to a heartbleed attack. This makes Heartbleed one of the potentially most damaging bugs I’ve ever seen.
I am wondering if this is somewhat similar to inbreeding. A lot of apps have the same little strand of DNA in them, and while that little piece gives us a lot of advantages, it comes with a deadly flaw. Since an entire ecosystem is carrying the exact same piece of DNA around, they are all vulnerable. Had we had more diversity, perhaps the issue would not have been so serious. Most people are going to be fine – but there are a group of users who visit awful websites who might be targeted by hackers. I think there will be easier ways of getting into regular users machines than through heartbleed – some people will actively download and execute an file if the filename and promise is tempting enough.
For example : Here’s a little executable I made, that will show you all of a certain blogs users and passwords obtained via the heartbleed vulnerability: Heartbleed.exe
* More in-depth analysis of the bug here
** Intels had a very fast JPEG decoder (IJL). Unfortunately it had a very small memory leak (8-16 bytes per frame) – this made XProtect Lite (Milestones first NVR) crash after a few days. John Blem (the CTO and co-founder of Milestone), went home, hacked the library and came back with a solution in a few days. I will never fully understand how he did it.