All this week, I’ve been following the news of the Heartbleed Flaw. If you haven’t heard if it — or if you have heard and don’t understand it — XKCD gives a good explanation. Basically, the flaw was an “old-school” programming error: someone allocated a buffer without clearing it first. In Orange Book terms, this was an “Object Reuse” error; the Common Criteria called it “Residual Information Protection”. Problems like this were common in old MS-DOS, where you could create a file, move the file pointer to some far out place, write a single character, and close the file. What would be left in the middle was whatever was lying on the disk. Heartbleed was the same thing:
When Heartbleed was first reported, panic ensued. You probably remembered this. This was the “Death of Commerce on the Internet!!!” Bruce Schneier (who I normally respect) said, “”Catastrophic” is the right word. On the scale of 1 to 10, this is an 11.” I, however, felt that panic wasn’t warranted. I’m pleased to see that, as time goes on, others are realizing that as well.
Does that mean this isn’t a serious problem? Au Contraire! Rather, it is a problem on the system owners end, who need to change all potentially exposed certificates. It is a problem for all the hardware devices that embedded OpenSSL in firmware in an unchangable and un-updatable way. All those devices have to be trashed and replaced. It’s a problem for all those who depend on others to maintain their web site. For example, I’m on Westhost. Here are their instructions to site owners regarding Heartbleed.
Why was this problem so great? OpenSSL was free code, so everyone thought it was good and used it. Forbes thinks this is indicative of a big problem with open source and its funding — there were about 4 people who were charged with maintaining this, all volunteer. Again, I disagree. The problem is not the funding or the maintenance, but the fact that the authors were not thinking about security from the get-go. They hadn’t been inculcated with secure programming practices that would have eliminated any object reuse issue. Being aware of how to write secure code eliminates many problems: boundary errors, object reuse errors, mishandling of input errors. All showed up here, and all are techniques any secure programmer worth their salt would know.
So, again, should you worry about this? You certainly shouldn’t panic. If you have an account on an affected site, then you might change your password if you are really worried about your data (e.g., I don’t care about Yahoo; my mail account there is only for spam) or you use that password elsewhere. If, by rare chance, you have exposure on a financial website or a government website, then do change your password.
Most importantly, get a little perspective. Although this is a lot of work for site owners, this isn’t anywhere near the headache of a Target breach, or the breaches we hear about every day where this database or that database of credit card numbers is exposed, or major medical databases are exposed. Worry about those. Most importantly, continue to consciously think about cybersecurity in whatever you do, and whenever you authorized information. For example, does the Facebook android app really need all those permissions it asks for?
