Threat Level: green Handler on Duty: Tom Webb

SANS ISC: What is using this library? - SANS Internet Storm Center SANS ISC InfoSec Forums

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
What is using this library?

Last year with OpenSSL, and this year with the GHOST glibc vulnerability, the question came up about what piece of software is using what specific library. This is a particular challenging inventory problem. Most software does not document well all of it's dependencies. Libraries can be statically compiled into a binary, or they can be loaded dynamically. In addition, updating a library on disk may not always be sufficient if a particular piece of software does ues a library that is already loaded in memory.

To solve the first problem, there is "ldd". ldd will tell you what libraries will be loaded by a particular piece of software. For example:

$ ldd /bin/bash =>  (0x00007fff9677e000) => /lib64/ (0x00007fa397b43000) => /lib64/ (0x00007fa39793f000) => /lib64/ (0x00007fa3975aa000)
    /lib64/ (0x00007fa397d72000)

The first line (linux-vdso) doesn't point to an actual library, but to the "Virtual Dynamic Shared Object" which represents kernel routines. Whenever you see an "arrow" (=>), it indicates that there is a symlink to a specific library that is being used.  Another option that works quite well for shared libraries is "readelf". e.g. "readelf -d /bin/bash" will list 

To list libraries currently loaded, and programs that are using them, you can use lsof. 

One trick with lsof is that it may appreviate command names to make the output look better. To fix this, use the "+c 0" option (or use a number that is long enough to help you find the right command). You can grep the output for the library you are interested in. For example:

# lsof +c 0 | grep libc-
init   1   root  mem       REG   253,0   1726296  131285 /lib64/
udevd  836 root  mem       REG   253,0            131078 /lib64/ (path inode=131285)
anvil 987   postfix  mem   REG   253,0   1726296  131285 /lib64/

The first column will tell you what processes need restarting. Also the number in front of the library (131285) is the inode for the library file. As you may note above, the inode is different for some of these libraries, indicating that the library changed. These are the processes that need restarting.

It is always best to reboot a system to not have to worry about remnant bad code staying in memory.

In addition, if your system uses RPMs, you can find dependencies using the RPM. But this information is not always complete. 


Johannes B. Ullrich, Ph.D.


3222 Posts
ISC Handler
I recommend adding '-n -P' to the lsof command line. -n prevents DNS resolution (which can add considerable delays to lsof running), -P prevents consulting /etc/services to turn port numbers back into port names. My fingers now add those two options by default when running lsof.
(My first reply didn't show up, trying again - my apologies if this becomes a duplicate).

Finding statically linked libraries could prove even harder. So I figured one could use Yara ( and/or possibly something like ssdeep ( to locate possibly vulnerable software on a disk.

By Googling [ yara statically linked ] I found which points out that I'm not the first one to consider this. Apart from providing a nice example, that page also points to prior art called F.L.I.R.T. (Fast Library Identification and Recognition Technology) in Ilfak Guilfanov's IDA (Interactive Disassembler), see and .

Is anyone aware of software tools (preferably open source) that can be used to scan a disk for software containing libraries (or even snippets) with possibly vulnerable software routines?
Erik van Straten

122 Posts Posts
I usually use lib_users to check for processes in need of restart:
git clone

1 Posts Posts

Sign Up for Free or Log In to start participating in the conversation!