Tag Archives: Information Security

The Heartbleed Bug

Image What is Heartbleed?

A new bug in the popular OpenSSL cryptographic software library has been found and it is incredibly terrifying.  OpenSSL is a popular open-source tool that a large majority of the Internet uses to encrypt data.  OpenSSL is an incredibly critical tool used by websites to authenticate data, like making sure it’s really your computer that’s communicating with your bank right now and not someone else’s.  This new vulnerability could lead to some potentially far-reaching exploits.  Here is a link to http://heartbleed.com/, a website created by Codenomicon to give you the more specific details regarding the bug.

Am I vulnerable?

The bug exploits servers for information; it doesn’t have a way of attacking an individual in the sense that it’s on your computer and actively gathering information from you.  It’s really difficult to tell whose affected and whose not at this point because the bug leaves no trace that you were attacked.  Several prominent sites such as Yahoo were shown to be vulnerable earlier this week, though I think at the time of this writing those sites have been patched.  Either way, it would be a good idea to change your passwords on sites you know are no longer vulnerable.  If a site is still vulnerable, there is nothing you can do as the encryption keys may be compromised.  So any password you change, the attacker can still easily decrypt.

Who’s responsible?

It is almost impossible to pin this bug on any one individual because OpenSSL is an open source project, which means that anyone can work on it.  Most of the people involved are very competent developers and even though it is open to everyone to contribute, every suggested change to the source code is reviewed and then approved or denied.  The weirdest thing about this vulnerability is how out in the open it was.  It wasn’t hidden or intended to never be found.  It was just sitting there, staring us right in the face.  It probably is the result of accidental sloppy programming as opposed to a malicious entity.  It’s also a very good reason why C can be such a dangerous and efficient language.  There isn’t a lot of things C won’t let you do.  Imagine the most literal person you can think of, and then multiply it by two and that’s the C programming language.  It does exactly what you tell it to, it doesn’t think about the safety or anything like that because that would slow it down.

How it works

Heartbleed is an interesting vulnerability in how it works because it is for the most part, fairly simple.  Essentially, an attacker can ask the server to give him a random 64 Kilobytes of memory.  The attacker doesn’t need to know what’s in those 64 Kilobytes, but he can continuously ask for this information until he can start putting together the important pieces, such as the encryption keys.  If the attacker successfully steals the encryption keys of a server, it is very bad news for that server because the attacker can now decrypt past and future communications with that server and even impersonate the service at will.  In case that doesn’t seem like a big deal, trust me when I say it is very very big deal.

The entire issue is centered around a function in the C programming language called memcpy, which stands for memory copy.  This function has 3 things that it takes as input: the destination, the source, and the size. Basically, memcpy is a function that takes a block of memory size big from source and moves it to destination.  The reason this is tricky is because in OpenSSL there was nothing verifying that what was in source was actually size big.  What this means is that someone can tell a server to open a block of memory size big but have nothing in source.  The newly created block still contains data from other services in the server but it has been prepared to be overwritten so it’s no longer needed at this very moment in time.  This data could be anything from random computer gibberish, to passwords, usernames and encryption keys.

Lets make this simpler to understand with the following scenario:  Lets say there’s a new store in town that trades in old boxes for new ones for some reason.  Not that lucrative of a business but a business nonetheless.   Now the owner of the store is a great guy, but he can’t count.  Like at all.  So you go to him with a box that has your shoes in it and you say “I want a new box that I can fit these shoes in”  and you give him your box.  He goes and takes out a box the same size as yours that’s filled with stuff that belong to other people. Before he can put your stuff in he has to take their’s out.  However, the owner only takes out just enough out to fit your first shoe, and then does the same thing for your other shoe.  Luckily, the box is the exact size and all the other people’s stuff is removed.  You take the box and you’re on your way.  This is how memcpy works normally.  Now lets say you’re a big jerk and you like to take advantage of the owner’s inability to count.  So you go down there and bring a big box filled with a pair of sandals and tell the owner you have a lot of stuff in this box.  So the owner takes out a box the same size as yours and starts replacing the items until your sandals fit, which isn’t a whole lot.  The box is still almost completely full with someone else’s stuff!   Now he sends you off, none the wiser, very pleased with himself because two sales in one day is quite an event for this man.  When I said he couldn’t count, I meant it; he has no idea how much stuff he put in there.  As far as he’s concerned, he went and got the new box, and set it on the table, and put something in there.  Even the putting something in there is a little foggy for him.  The other people’s stuff in the box is the data that was ready to be overwritten, the boxes were the blocks of memory, and the owner was the memcpy function.  The owner has no idea what stuff is in the box other than that no one needed it anymore.  That’s basically how the bug works, and it’s a form of a buffer overflow attack.

Why should I care?

This bug is terrifying is because of how many servers are vulnerable and how hard it is to detect.  This will require a lot of due diligence on the part of server administrators to ensure they’re on the newest version of OpenSSL.   Codenomicon estimates that approximately two-thirds of Internet sites uses OpenSSL for encryption, and who knows how many of those are vulnerable or not.  That’s millions of websites that could be susceptible to this bug.  I will repeat myself to reemphasize this point: change your password on sites that are no longer vulnerable.  If you’re unsure whether a site is vulnerable or not, try doing some digging on the site’s news updates or look if they have a list of updates and hot fixes.  If a site doesn’t tell you if it was vulnerable or not then I would caution further use of that site.  They might not be actively updating it, may be unaware of the bug or they don’t want you to know, which is worse in my opinion.

Let’s just hope that this hasn’t been in the wild for too long, otherwise the Internet really will bleed.

 

 

 

sources: http://heartbleed.com/

Tagged , , , , , , , , , , ,