It seems that it’s only been a few weeks since we all heard of a nasty certificate validation error in Apple’s software, a.k.a. the infamous “double goto fail” bug. While some were quick to point out that Linux distributions were not vulnerable to this particular issue, wiser heads cautioned that a similar bug could be potentially lurking in software used on Linux.
And, seemingly just to illustrate this point, we now know that a popular free software library, GnuTLS, failed to correctly validate some X.509 certificates in a way that is very reminiscent of the bug that affected Apple.
What is GnuTLS?
If you’ve never heard of GnuTLS, it’s not really because you have been living under some kind of IT security rock. GnuTLS is an encryption and certificate management library that was written for a specific purpose — to write a feature-complete replacement for OpenSSL that can be legally linked against GNU GPL-licensed code. While OpenSSL is Free Software by any definition, it is made available under the OpenSSL license that imposes conditions that are incompatible with software released under GNU GPL. Any programmer working on GPL-licensed code who wanted to use a cryptography library could not legally use OpenSSL, and therefore GnuTLS was written as a GPL-compatible replacement.
A few years after GnuTLS became available, Mozilla released its own security library, called NSS (“Network Security Services”), which was also licensed in a way that was GPL-compatible. So, really, there are three popular free software libraries that do similar things today:
- OpenSSL, under the OpenSSL license (Not GPL Compatible)
- GnuTLS, under the GNU LGPL license (GPL Compatible)
- NSS, under the MPL license (GPL Compatible).
They all do similar things to work with the same X.509 and SSL/TLS standards, but other than that they have nothing in common and share no code.
Is this the same as Apple’s “goto fail” bug?
The bugs are similar in the sense that they both allow invalid certificates to pass validation checks. The exact impact of the vulnerability is still being established, but we should assume that a dedicated attacker can successfully trick an unpatched version of GnuTLS into validating a certificate that is otherwise bogus. This would allow someone with malicious intent to perform a “Man-in-the-Middle” attack by intercepting a TLS connection attempt from your system to a remote server and pretending to be the server with which you are trying to communicate instead.
In terms of a real-world example, if you go to a cafe and fire up your mail client to check your mail over the free wi-fi, what you think is “mail.google.com” may be an attacker’s laptop at the next table, to whom you just sent your Google credentials.
Certificate validation is pretty much the core basis for secure communication using TLS, so when a bug is found in the validation routines, it is nearly always treated as critical.
What software uses GnuTLS?
Quite a few things installed on a Linux workstation use GnuTLS. If you’ve been using Firefox to browse the web, then you are safe, as it uses NSS. However, Chromium (and Google’s Chrome) relies on GnuTLS, as do other webkit-based browsers. Mail clients such as mutt and claws-mail are vulnerable, but Evolution and Thunderbird aren’t.
Most server daemons tend to use OpenSSL or NSS, so your Apache or Nginx server are not affected. Java software includes its own TLS implementation (JSSE) that doesn’t rely on GnuTLS, so you’re safe there, too.
The list is quite long, so it’s impossible to write a comprehensive summary of what is vulnerable and what is not. Instead, what you really should be doing is routinely applying security errata to your systems.
How to check for security errata with yum
Various distributions of Linux use their own mechanisms of applying patches, so it’s impossible to provide a comprehensive article that would be applicable to every distro under the sun. Since I am a RHEL sysadmin and a Fedora developer, I will therefore concentrate on the software management system I know best — yum.
Both Fedora and RHEL (and its beige-box cousin, CentOS) helpfully provide extra information alongside its errata packages that you can use to see whether there are any security-related updates available for a system you administer. To tap into this information, first install yum-plugin-security:
# yum -y install yum-plugin-security
Now you should be able to list outstanding security errata for your system. Here’s one for a RHEL 6 server that hasn’t yet received the gnutls patch:
# yum updateinfo list security [...] RHSA-2014:0246 Important/Sec. gnutls-2.8.5-13.el6_5.x86_64 RHSA-2014:0222 Moderate/Sec. libtiff-3.9.4-10.el6_5.x86_64
You can then find out more about each security advisory by running:
# yum updateinfo "RHSA-2014:0246"
Or you can find out the exact CVEs (Common Vulnerability and Exposure numbers) that are applicable to your system:
# yum updateinfo list cves
Or to that specific gnutls update:
# yum updateinfo list cves "RHSA-2014:0246" CVE-2014-0092 Important/Sec. gnutls-2.8.5-13.el6_5.x86_64
If you want to apply all outstanding security errata to your system, you can do so by running the following command:
# yum --security update-minimal
The takeaway
Regardless of whether you use Linux on a server or on a workstation, it’s very important to always keep your system updated by routinely applying relevant security errata. All software contains bugs that must be patched on a routine basis — whether you use proprietary platforms such as Apple, or a free software distribution based on Linux. Failing to do so will leave you vulnerable to attacks.
