A Layman’s Guide
to Heartbleed, David Pitts, April 18, 2014
Originally published on http://www.dpitts.com/2014/04/a-laymans-guide-to-heartbleed.html
The modern world relies on computer security. Unfortunately, the modern world also takes security
for granted. My goal with this article is
to write about the Heartbleed security flaw so that non-technical people can
understand what it is, what its impact is, and how to help protect themselves
and to be able to have an intelligent discussion about it. I try to limit the technical jargon, but
given it is a technical topic, some will have to be there. The reader can search the internet for
“CVE-2014-0160” or visit http://heartbleed.com/
to get a more technical understanding.
The Heartbleed security flaw has been all over the news the
past couple weeks and rightfully so. Its
official reference is “CVE-2014-0160”, but that’s hard to remember and hard to sensationalize
in the news. The flaw is part of the
software that allows and responds to “heartbeat” requests. So, it gets called the Heartbleed bug as a
play on words. This is (hopefully) the
worst security flaw the computing world will see exposed this year. I say this, not because I know what has yet
to be exposed, but because I understand what this one does and can do. Generally when I think about security I
break it down into three major factors – impact, severity, and difficulty.
- Impact: How prevalent is it – in other words, how many systems and services are potentially affected. Also, how many users are potentially affected.
- Severity - How much damage can it do – what is capable of giving or exposing and to whom?
- Difficulty - How difficult is it to exploit – do you need special access or knowledge, etc. This would also include whether an exploit has been made available “in the wild”.
For Heartbleed, it is the trifecta of security flaws. It has very high impact, very high severity,
and very easy to exploit.
What is it
Heartbleed is the term that has been given for a flaw in
some software used to encrypt data. It
is not a virus. You can’t update your
antivirus and be protected. The software
is part of the OpenSSL project. The
particular bug was in the transport layer security protocol. If you want to know more about the heartbeat
protocol, search the internet for RFC6520.
Where is it
It is used for web sites, network equipment, mobile phones,
firewalls, etc. Basically, it could be
anywhere where developers have wanted to secure a transmission and have used
this library. The fix, therefore, is for
organizations to be responsible and to fix their services. According to heartbleed.com, about 2/3rds of
all servers on the internet use software that uses the OpenSSL library. Some percentage of those potential servers
was actually affected.
Why is it
It was a human mistake.
One of the nice things about open source is if you have the inclination,
you can see who wrote the code, when it was made part of the library and
actually look at the code.
When
It was found by several groups around the same time. Google reported it on April 1, 2014,
Codenomicon (a Finnish cybersecurity company) discovered it on April 3rd. They are the ones that named it and then put
up the heartbleed.com web site to explain it to the public. In giving these dates, I am presuming that
some security agency didn’t find it before then, so they don’t get credit. The bug was analyzed and verified. The organizations contacted the OpenSSL group
and reported the flaw. A patch was put
in place and released on April 7th and the bug was publicly
disclosed the same day. The code that
introduced the bug was written in 2011 and became part of OpenSSL March,
2012. Rumor has it various entities have
been exploiting this bug for months if not years. One such story was published here: http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-been-exploited-months-before-patch/.
I’m a fairly paranoid person, so I don’t believe that two independent
organizations within two days of each other found the same bug. I would be more willing to believe they were
led that direction or that they were working together or that they were tipped
off, or some other such story. I just
have a hard time suspending my disbelief for such a coincidence.
What does it do
The heartbeat protocol is a way to keep a communication
conversation from timing out. It ensures
that the peer can be reached and is alive.
In computing terms, starting and shutting down a secure communication
stream is much more work for the computers than maintaining an open connection. The basic concept is that almost any time a
“heartbeatrequest” can be sent. The
receiver then responds with a “heartbeatresponse”
But, what does it respond with? Since computers can’t do random, it can’t
pull something out if its magic hat, instead it pulls data from memory
somewhere near what it is working with.
As a heartbeat response is just supposed to be a single character
response, pretty much any single character response will do. (I am reminded of Sean Connery’s character in
The Hunt for Red October requesting “just one ping please” - https://www.youtube.com/watch?v=jr0JaXfKj68.)
If that was the extent, then there wouldn’t be a
problem. The problem is that the way the
code was written, the requestor can change the size of the request. Instead of one character, say an “A”, it can
request up to 64K of data. That is 64536 sequential characters from
memory. Technically speaking, the memory
that it is reading has been marked to be reused. However, computers don’t clear out the old
data, it just over writes it. I used to
do the same thing with my file folders.
I had a file folder labeled “Windows NT”. I then took another label and put it on it
that said “Red Hat Linux”. If you lift
up the old label you can still read the label underneath. To put it another way, let’s say you ask me
for a playing card. I’m supposed to give
you one playing card. So, I reach in,
and I pull out a playing card and I give it to you. You then come back and say, “Hey, I want a
playing card, give me 10 of them.” So, I
see the request for a playing card, and I give you 10 of them (or sixty-four-thousand
of them).
Another aspect of this bug that makes it even more insidious
is that in by far the majority of the cases, the exploit is not logged. The device being affected would have to
monitor both the incoming and outgoing traffic and notice that a single byte
was requested but more than one byte was delivered. The request isn’t going to a normal service
(such as the web server itself), so that service is not logging it. When you hear it said that there is no
indication that it has been exploited.
The statement is true. However,
the statement means nothing. I don’t know
Latin, but I’m sure there is some Latin phrase that means “listener beware
because the speaker is spouting doo-doo”, maybe something like “Qui audit,
dicentis implebitur fimo” if http://translate.google.com
is to be believed.
As a consumer, what
should I do?
This is the tough part.
The real answer depends on many factors.
I used to say that there is no such thing as security. The only way to make a computer secure, is to
unplug it, put it in concrete, once the concrete sets, dig a deep hole, put it
in the hole, bury it, and then forget where you buried it. However, I am not convinced that this is
secure either.
The question is really about what is secure enough? The data you have on a social media account
(Facebook, Twitter, Google+, Youtube, Pinterest, etc.) is supposed to be fairly
public. The data you have at your bank
or the doctor’s office is supposed to be fairly private. Now, treat it that way.
The media is telling you to change your passwords. This is a good idea. However, if the service is still vulnerable,
then changing your password doesn’t help much, does it? So, you want to make sure that the service
you are using and care is secure is not vulnerable – at least as best you can.
Unfortunately there
are a couple problems here.
First, at least in the United States, there have been laws
on the books since the mid 1980’s trying to define what is legal and what is
not. I’m not a lawyer and I don’t play
one on the internet. There are people
trying to figure this stuff out (http://www.fas.org/sgp/crs/misc/RS20830.pdf
for example), but it seems to be a slippery slope. If you test the service, you may or may not
be violating laws.
Second, the current set of tools is only partially
accurate. Many organizations have
released heartbleed checkers that you can run against websites, add as
extensions to browsers, etc. While I do
not endorse any of them, the list includes http://filippo.io/Heartbleed/, https://lastpass.com/heartbleed/, https://chrome.google.com/webstore/detail/chromebleed/eeoekjnjgppnaegdjbcafdggilajhpic. What the
industry is finding is that various tools are looking for something specific
that may or may not be accurate.
In the US we live in a world where we feel we have very
little control. The rich, the law
breakers, the “man”, or whoever, makes the rules and all we can do is try to
cope as best we can within the constraints we are given. Public awareness is probably the greatest
tool.
When former President Ronald Reagan said “Trust but Verify”
(https://www.youtube.com/watch?v=As6y5eI01XE)
he was referring to the treaty between the US and Russia over nuclear
arms. This concept is a good one and one
that should be followed here. Is the
organization transparent in its treatment of security in general? They should be. Is the organization transparent in its
treatment of this and other bugs? They
should be. As a consumer, your job is to
ask, and expect an answer. Ask publicly,
and expect a public answer. There are
several lists out there that will tell you some of the sites that were affected
by the heartbleed bug. One such site is
Mashable (http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/). As mentioned earlier, this bug, in almost all
cases, does not get logged. When they do
tell you that “Currently, we have no indication that any of customers’
information was compromised “as one email I received on April 13th
stated, then you know they are telling you the truth. It doesn’t mean anything, but it is the
truth.
In an article on americanbanker.com (http://www.americanbanker.com/issues/179_75/heartbleed-bug-lurks-beyond-websites-1066969-1.html?zkPrintable=1&nopagination=1)
on April 17th, JD Sherry is quoted to say, “We don’t know the
breadth or depth of this yet.” I know JD. He is
right. We don’t. As a consumer, our job is to make sure that
our providers are being responsible. JD
said in the article that it may take “weeks and months to get people’s arms
around this, and quite frankly some people are never going to get to the patch
all their systems, which is a scary thing.”
Again, JD is correct, it is scary.
Hopefully
the lesson from this is that we need better transparency from our service
providers. We need a more mature
security model, particularly for those services that contain protected data,
private information, health information, and personally identifiable
information that the consumer wants kept private. This also means that we, as consumers, need
to be better informed. Hopefully, this
article has helped with that.
Mr. Pitts is a seasoned technology executive with over 30
years technology and operations experience including 10+ years senior technical
executive management and 16+ years total management,. Mr. Pitts has
experience planning, developing, and implementing large distributed
environments, public and private cloud computing platforms, utilizing
resources, and managing projects and staff in such areas as E-Government,
Internet, manufacturing, healthcare, and higher education. He is adept at
crisis management, trouble shooting, problem solving, and systems
architecture. He is a trained educator, published author and an
experienced public speaker.
1 comment:
Very good write-up of this issue, David.
Post a Comment