GnuTLS Bug Part 2: What Components Were At Risk?

A week ago I warned you about the GnuTLS bug. You have patched your systems, right?

This is big, and it’s hard to say just how big it really is. A lot of network clients and servers need to use SSL/TLS, but they can call on libraries from various sources. They might be compiled in a way that links them against the GnuTLS shared libraries. Or the same applications could use the OpenSSL implementations. Or, they might rely on implementations within the operating system, as can be the case on Microsoft Windows. An open-ended risk is worse than a known problem, as you don’t know just what problems you have, how big the total risk is, and how do know when you’re done without looking at every last component in detail?

I wrote earlier about the BEAST attack, we discuss it and how to mitigate it in Learning Tree’s Cloud Security Essentials course, and I have more on the topic here. The BEAST attack continues to matter because developers of web browsers and web servers used a silly game of mutual blame to keep common web security technology some 8 years or more behind the current state of the art. TLS v1.1 fixed the problem in April 2006, but the vast majority of HTTPS servers run TLS v1.0 or even earlier.

There has been, or at least there has appeared to have been, better hopes for organizations developing and running their own applications, possibly in PaaS and IaaS cloud platforms or maybe in their own networked client-server systems. In those situations they could use, you guessed it, the GnuTLS shared libraries. Or maybe they used OpenSSL libraries. Or maybe (on Windows) they used the OS components.

If you designed, developed, compiled, and run your own software, then your designs and configuration management should be able to remind you of precisely what you did. But what if (blush) you lost track, and what about all the applications that came with your operating system? We may know about few — Chrome, Firefox, and Thunderbird all use the Mozilla Network Security Services libraries. What about everything else?

Here’s a script to find a list of all ELF binaries using GnuTLS on a system, assuming that the shared library is stored in /usr/lib/libgnutls* or similar. You should have already patched GnuTLS, so this gives you an estimate of the risk you were running before the patch. Run this as root and be patient:

#!/bin/sh

# Build a list of all programs using shared libraries.
# These will be files for which the "file" program reports:
#   /path/to/file/name: ELF .....(uses shared libs)...
FILES=$( find / -type f -exec file {} ; |
                awk -F: '/ELF.*shared libs/ {print $1}' )

# ldd lists the shared objects used by a program.
# Part within "$(...)" happens first, it's just the libgnutls
# reference, if any, otherwise it's empty.
# Output of echo is the file name plus (maybe) "libgnutls"
# awk then selects just the first field (the file name itself)
# only for those lines containing "libgnutls"
for FILE in $FILES
do
  echo $FILE $(ldd $FILE | grep libgnutls) | awk '/libgnutls/ {print $1}'
done

Your in-house systems are patched. Next week I’ll tell you how to patch newly-deployed IaaS cloud servers. Yes, you still must do that!

Bob Cromwell

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.