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
    linux-vdso.so.1 =>  (0x00007fff9677e000)
    libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fa397b43000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fa39793f000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fa3975aa000)
    /lib64/ld-linux-x86-64.so.2 (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/libc-2.5.so
udevd  836 root  mem       REG   253,0            131078 /lib64/libc-2.5.so (path inode=131285)
anvil 987   postfix  mem   REG   253,0   1726296  131285 /lib64/libc-2.5.so

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.
STI|Twitter|LinkedIn