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.
How does a person protect them selves? ….in layman terms please!!
Errrrrrrrr, a very good question 🙂 And tricky to answer, which is why I sort of skipped it in the article…
If you have Windows or a Mac, you won’t have gnutls installed by default. That mitigates your risk a lot.
But you might have some applications installed that ship with it. If they include “call home” or autoupdate features, they _might_ use gnutls, but there is no easy way to tell.
Generally speaking, Microsoft products like IE, Outlook, Office and so on are immune. And as far as I am aware, no Sophos products use gnutls, so we’re OK. But the only way to be sure (you didn’t want to hear this) is to check the documentation of each product or ask the vendor.
If you have Linux, you very likely do have gnutls installed centrally, so a single security update from your distribution ought to fix the problem, but you still might have some applications installed that ship with their own copy. To find out if they do, see above.
For what it’s worth, the licensing terms of GnuTLS mean that any program that uses it ought to tell you, somewhere obvious, in its manual or on its website.
Sadly, problems like this are a bit like saying, “If your car has a fanbelt than was sourced from the Acmefactory in 2012, it could wrap itself round the snedley and extrunge the grimmet lubricator assembly.”
It’s important to let people know…but which cars does it apply to? You can open the bonnet (hood) and look, if you know where to look. You can try to read the vendor’s name on the belt, if it hasn’t worn off. Even then, you don’t know which factory the vendor sourced the belt from. And if you did…does your car even have a snedley? Or a grimmet, lubricated or otherwise, that is at risk of assembly extrungement?
Sorry I don’t have a clearer, simpler answer.
(This might be a great topic for a Techknow podcast!)
Ok. Confused…lol :/
Well, since I had a Windows File Manager open from earlier, I just selected “Computer” and ran a search on the entire system for “gnutils”. 2 programs show multiple hits: “Pazera Converter” [ffmpeg*.txt – 2 files had “–enable-gnutls” didn;t check the rest – 14 total, but imagine similar] and “Libre Office” [license.txt/,odt/,html]
I was looking for a list of programs that make sure of GnuTLS, and found someone wrote a script to generate a list for Debian:
http://www.reddit.com/r/linux/comments/1zm1r7/list_of_debian_packages_which_depend_on_gnutls/
Actually, that was 3 months ago. Does this library have on going problems?
The three-months-ago problem related to certificate validation…if I am remembering correctly. This was recently patched; see the link above to the Radare blog article for more info on the what and when.
The Debian script is still valid, of course, as a way of tracking packages that use GnuTLS. If anyone has scripts for other, non-APT-based distros, feel free to let us know.
As an example of vulnerable non-desktop software that uses GnuTLS, I highly suspect that routers whose firmware is based on Linux are likely to be running GnuTLS and should be patched. DD-WRT is verified to not be susceptible to this, but there are many other Linux-based routers out there (commercial as well as open source firmware solutions) that may be.
I just searched my Mac for “GnuTLS” (I used Find Any File.app; the castrated search functions in OS X haven’t been able to find invisible files since Tiger).
I found an instance of “_gnutls” on my system drive at usr/share/zsh/4.3.11/functions/. I also have “libgnutls_plugin.dylib” and libgnutls.26.dylib” for VLC.app and/or GraboidVideoMac.app.
If those are the only apps that use GnuTLS, then presumably installing updated versions of those apps (assuming they’ve been patched) should solve the problem…er, right?
I’d say you’re right.