Move over Heartbleed – here comes another SSL/TLS bug

Here’s a question.

Which widely used open source SSL/TLS cryptographic library just recently fixed a critical bug caused by a buffer overflow?

I’ll give you a clue.

The buffer overflow was in part of the protocol that helps to manage the connection, rather than anything to do with the actual sending and receiving of your private data.

Yet the hole could be exploited to leak your own and other people’s information.

That’s right!

It was OpenSSLGnuTLS.

Move over Heartbleed, here comes…

…well, this bug doesn't have its own fancy logo or media friendly name.

We'll just call it CVE-2014-3466, or 3466 for short.

Compared to Heartbleed

Heartbleed could be exploited from both sides of the conversation, with either the client (i.e. the computer that initiated the connection) or the server (the computer connected to) poking the other end to leak up to 64KB of semi-arbitrary process data.

3466, on the other hand, only works from the server to a connecting client – so you don’t own the server; the server owns you.

Here’s what happens.

When you connect, the server sends a lump of data called the Session ID as part of what’s known as the Server Hello.

This is a magic data string that can be used in subsequent TLS connections from the same client to resume the current session, if both client and server agree.

Resuming a session is quicker than going through the entire cryptographic song-and-dance of establishing a new one, so this is an optimisation that can be used to improve throughput.

As long as a session ID isn’t kept alive for too long, security isn’t at too much risk in doing this.

It’s a bit like the extra 20 minutes you get after you pay for your parking ticket in a multi-storey car park, to give you time to drive to the exit and leave.

The buffer overflow

Except that in GnuTLS, until it was recently patched, the client did this:

• Read in a byte from the server denoting the length of the session ID string, say, N.
• Read in N bytes of session ID.
• Copy those N bytes into a pre-allocated buffer of 32 bytes.

32 bytes is 256 bits, and a perfectly reasonable choice for the maximum session ID length: more than enough for a randomly-chosen session ID never to repeat by chance.

But 32 bytes just isn’t enough if a rogue server decides to send a Session ID of, say, 250 bytes instead.

So this is a classic buffer overflow. (The internet worm exploited one, 25 years ago.)

It’s been patched, but a blog post on the website of open source reverse engineering toolkit Radare explains why this vulnerability can almost certainly be exploited on unpatched systems.

In other words, connecting to a malevolent server could cause a denial of service against your computer, because the connecting process will crash.

Or it could even cause a remote code execution, where the N byte rogue Session ID includes executable shellcode that takes over control of the connecting process.

Remote code execution could mean a drive-by install, where the remote end of the connection gets to shovel software onto your computer without any popups or security warning.

What’s at risk?

Just like Heartbleed, this hole goes beyond HTTP connections from a browser.

Any client-side software that uses GnuTLS for transaction security could be at risk.

On a typical Linux system, for example, many, if not most, programs relying on GnuTLS will use a centrally-installed copy known as a shared library that should be managed by your distro itself.

Updating this centrally-installed shared library will implicitly patch any software that depends upon it.

But other software might include its own copy of GnuTLS, and will need patching in its own right.

The new GnuTLS versions with the patched code are: 3.1.25, 3.2.15 and 3.3.4.