In April 2014, Heartbleed hit the headlines. It was a relatively simple
coding mistake that threatened to bring the entire Internet to its knees,
completely undermining the fundamentals of electronic security. But how did it
happen, and could it happen again?
Welcome back to the Pro Tech Show - the place for tech, tips, and advice for IT
Pros and decision makers. If that sounds like your kind of thing then hit that
subscribe button. Today we're looking back at the
Heartbleed bug - a relatively simple coding mistake that turned the internet
inside out back in 2014. How did such a little mistake cause
such a big impact? Heartbleed was a bit of an oddity. It was one of the first
bugs to get a logo and a memorable name. Most bugs were known by their official
CVE reference number - Heartbleed's being CVE-2014-0160. Memorable, huh?
It start a bit of a trend of bugs with exciting names and cute logos. There
been a few since then. Arguably, most bugs with logos nowadays are just the
result of security researchers doing a bit of marketing to try and raise their
own profiles; but Heartbleed's had a specific purpose. Heartbleed was felt to
be so dangerous by the people who discovered it that they give it this
media-friendly face to try and get the news out. The worry was that so many
people were going to be hit by it that they needed to get it into the public's
consciousness as quickly as possible. So what was the big deal about Heartbleed?
What made it so dangerous? Well, Heartbleed affects TLS. TLS is a
cryptographic protocol that underpins the security of most electronic
communications today. When you do your online banking you're using TLS. Ehen you
log into Facebook you're using TLS. When you buy something on Amazon you're using
TLS. You're using TLS right now to watch this
video. You may also heard of SSL. That's just
the old name for TLS. They're the same thing. Heartbleed isn't a bug in TLS
itself. It's a bug in OpenSSL. That's a software library that happens to be the
most widespread implementation of TLS. OpenSSL is free for anyone to use, and a
lot of people do. It's the dominant implementation on Linux, and therefore
most of the Internet. OpenSSL is one those software libraries that is so
widespread everyone just kind of trusted it. So here's the background.
It wasn't the encryption itself that had failed. The "heart" in Heartbleed refers to
the heartbeat extension for TLS. There's a bit of work that goes on between your
computer and the server when it wants to set up an encrypted session. Tt doesn't
make sense to repeat that process every time you want to send data.
That would be hugely wasteful. So instead your computer and the server keep that
session open. But how long should they keep that open? There's other people want
to use a server, so it needs to know when to close it. In an ideal world your
computer would say goodbye to the server when it was done, and the server would close the
session. In the real world this might not happen. Your computer might crash. You
might have a power cut. You might be running some badly-written software that forgets
to say goodbye. In that case the server would hang on to the session forever,
and over time it would collect more and more of these dead sessions until eventually
it would crash under the load of trying to maintain them all. One solution is for
the server to start a timer, and if it doesn't hear anything from you by the
time the timer runs out it closes the session. But how long should that timer
be set for? Computers consume data in milliseconds, but throw a human into the
mix and it can take significantly longer. If you're reading a long article on a
website for example, that could take several minutes. The solution is for your
computer to send a little heartbeat message every so often; just to let the
server know you're there, even if you've got nothing to say. Every time the server
receives one of these heartbeat messages it resets the timer. This little
heartbeat message is where things went horribly wrong. We're about to get a
little technical here so bear with me. Everything that happens in a computer
happens in memory. Data, programs, anything to be processed, anything has been
processed... at some point it lives in memory. The heartbeat process is quite simple:
your computer sends a message, the server replies with the same message, and in
between it lives in memory. A server's memory is a very cluttered place. Space
for the heartbeat message gets allocated wherever some space is available. That space
is not going to be empty. It will contain whatever data was left behind by
the previous program that used it. It's ready to be overwritten, but it's not
actually blank. Erasing it would be a waste of time when you're going to
overwrite it anyway. Now here's the bug. The heartbeat message can be any length
up to 64 KB. The first part of the message tells server how long it is
so the server knows how much space to make available for it. But what if you
send a 1 KB message and you tell the server it's actually 64 KB
long? That's what Heartbeat does. The problem is
that the server allocates the full 64 KB of memory and
only overwrites 1 KB of it. Now that would be okay if the server made a
note of the discrepancy, but it doesn't. When it comes time to reply, it looks
for the length of the message and instead of taking the 1 KB it
actually received, it takes a 64 KB number that you told it. So it reads 64 KB
out of memory and sends it back. Now 1 KB of that data it
replied with was your message. What about the other 63 KB? Well it's
whatever the previous program left behind in that memory. It could be
anything - it could be program code, it could be data, it could be complete rubbish,
or it could be really really sensitive. There's no way of knowing at this point.
Bearing in mind this bug exists in an encryption protocol, and we tend to use
encryption when we want to protect something valuable, and you can see the
problem. Heartbleed is essentially a lucky dip. It tricks the server into
sending you random information from memory. You don't know what you're going to
get, but you can keep trying to over and over again until you get something juicy.
Take an e-commerce site for example. That information could be someone's username and
password, their home address, their credit card number, or even the encryption keys
of the server itself. Heartbleed has often been thought of as a Linux problem
because open SSL was the dominant TLS library in Linux. That by itself is
enough reason to worry, because a large portion of the public Internet runs on
Linux. In the corporate world, however; it's more common to see Windows servers
than Linux servers, and Windows tends to use Schannel rather than OpenSSL. Does
that mean corporate servers were safe? No. A lot of servers (Windows or Linux) use load
balancers to manage traffic to them, or they use security devices like reverse-
proxies or web application firewalls. And what those devices tend to run? You
guessed it. Linux. And even if they don't, there's a good chance they're using OpenSSL
anyway. It didn't matter what your servers run. It mattered what the device
people connected to first used; because that's where the bug was exploited.
Websites got a lot of attention here, but bear in mind that TLS is used for a lot
of things, not just web servers. It's used for emails, VPNs, firewalls, all were
affected. So how did this happen? Well, for such a critical piece of
software, OpenSSL was chronically underfunded.
It was maintained by a handful of volunteers and it survived off the
donations totalling about $2,000 per year.
Remember that a large portion of the internet runs off this software! The code
that contained the Heartbleed bug was submitted by a German PhD student and
quickly approved by a British consultant. It was committed at 11:59 p.m. on the
31st of December 2011. That's one minute to midnight on New Year's Eve! Somebody
needs to get out more; and that's coming from a guy who makes IT videos in their
spare time! Anyway, people got the code in 2012 and it went undiscovered until 2014.
The obvious question is: could this happen again?
Of course it could, but there is some reason to be hopeful. Heartbleed caused a
lot of people to take a much closer look at critical open source projects.
Oroponents of open source have long claimed that open source software is by
nature more secure than traditional closed source software. The theory is that
with the code publicly available, everyone can review it, and with loads
and loads and loads and loads and loads and loads of people reviewing it you're gonna find
and fix a lot more problems. That's more of a belief than the fact though; and
it's difficult to prove one way or the other.
What Heartbleed clearly proved though, is that just because everyone can review
your code, doesn't mean anyone actually will. In fact there's evidence that
Heartbleed was being exploited before it was supposedly discovered - implying that
the bad guys did review the code, did find the bug,
and then kept it to themselves so they could use it. I mentioned good news, right? Well,
this has prompted a lot more critical interest in open source software, and
tech giants like Google have started reviewing the code in earnest. Suddenly,
funding was available for critical projects like OpenSSL as well. so
hopefully we're all in a better place now and less complacent about the
software we use every day. Ultimately though, one human made a mistake, another
human missed it, and we got Heartbleed. Could that happen again? Of course. Us
humans aren't going anywhere, and humans will always make mistakes. So what can
you do about it? Well, the simple answer is patch, patch, patch. Keep the systems
up-to-date, keep the bugs at bay. That's it for today folks. Let me know what you
thought of the video, and if you want me to make a series of this and look back
at other major vulnerabilities, then drop me a message in the comments.
if you made it this far then hit that like button, and go subscribe. If you want
to be notified when the next video's out in a couple of weeks time, use the bell
icon. Thanks for watching, guys. See you next time!