After installing updates to address CVE-2014-0160 (the OpenSSL Heartbleed bug), I had to take care to restart anything that might be using libssl — many services, such as Apache and my VPN software, still had the old vulnerable libssl loaded up, and my package manager made no attempt to rectify this.
This got me thinking: After I update a shared library, how can I reliably find out which running programs currently have an old version of the library linked in? I am sure there must be a way to interrogate running processes either at the linker level or at the file descriptors level to determine whether the instance of a given shared library they have loaded is the same as the one currently on disk.
Best Answer
I found two ways to do this:
/tmp): Thedebian-goodiespackage containscheckrestart, which accomplishes something like what I've described by scraping the output oflsofto find open files that are gone or replaced on disk. It identifies the processes in question and (if possible) the package to which they belong and any init script that can be used to restart them. The-voption will identify the files concerned.Generic, manual, allows specifying the file you're worried about: You can look at the output of
lsofto identify open file handles to deleted or replaced files. In the output oflsof -nnP, such a file appears to be identified byDELin the fourth column. You can do something likelsof -nnP | grep DEL.*libssl.soto look for stale handles to a particular library (OpenSSL, in this case). This is probably highly dependent on the specific version of lsof you use and the behavior of your package manager, so proceed with caution.