What is using this library?
Last Updated: 2015-02-03 16:54:01 UTC
by Johannes Ullrich (Version: 1)
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)
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.
Feb 4th 2015
8 years ago
Finding statically linked libraries could prove even harder. So I figured one could use Yara (https://plusvic.github.io/yara/) and/or possibly something like ssdeep (http://ssdeep.sourceforge.net/) to locate possibly vulnerable software on a disk.
By Googling [ yara statically linked ] I found https://www.nccgroup.com/en/blog/2014/06/writing-robust-yara-detection-rules-for-heartbleed/ 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 https://www.hex-rays.com/products/ida/tech/flirt/index.shtml and https://www.hex-rays.com/products/ida/tech/flirt/in_depth.shtml .
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?
Feb 4th 2015
8 years ago
git clone http://git.schwarzvogel.de/repos/lib_users/
Feb 5th 2015
8 years ago