Auditing your Linux libraries

TL;DR just because you patched libpng doesn't mean that you're server isn't still vulnerable

Last week I posted about the need to audit the libraries that are used by your software.  In the post last week, we talked about the fact that Dropbox was using a version of OpenSSL with numerous public vulnerabilities. 

The post could not have been much more timely.  It turns out that vulnerabilities were recently discovered in libpng.  In my minimal searching, I’ve been unable to locate any Windows software using libpng, but I’m betting it’s out there somewhere.  However, libpng is used in numerous open source projects on the Linux platform.  That’s right, it’s time again to check your libraries. 

But how do you know on Linux whether you application uses libpng?  That’s where the ldd tool can come in tremendously handy.

root@kali:~# ldd -r /usr/bin/yersinia 2>/dev/null |grep libpng
    libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb6875000)

Rendition Infosec has put together a simple bash script to help you check your system for binaries that dynamically load libpng.  Certainly you could put together a MUCH more robust script but this will suffice more most users.

You need not patch all of these applications, simply updating the library will suffice in most cases.  But is the system secure then?  Probably not…

There are two additional cases you should test for.  Unlike Windows, Linux supports deleting library files that are currently in use.  Also unlike Windows, your Linux server has probably been up for months or years.  This means that you might have a library that has been updated on the system (it might even be deleted) but it continues to be loaded into a long running application (like a system service).

To check for this case, examine /proc/<pid>/map_files.  It is important to note that even if you remove the old library from the system, the library isn’t really gone until there are no dangling references to it.  This is true even if you can’t see it on the filesystem.  Examining /proc/ will help you determine which processes must be restarted to take advantage of the new library.  Rendition Infosec has put together a quick bash script to help you identify processes currently running that need to be restarted to take advantage of the library upgrade.

The other case to consider is that libpng might be statically linked into an executable.  This is unfortunately more difficult to discover.  Running strings on the binary and checking for libpng (and libpng related strings) is one option for checking.  Another is checking configure scripts for your software (if you build from source).  Given the flexibility of dynamic shared libraries, it is increasingly unusual to see statically compiled programs.

Hopefully this post helps you keep your job (or look like a rock star) when the next Linux library vulnerability is released.