3 ms·
Here's a .deb version; only running debsums once per package name. Errors will go to stderr: sudo lsof | grep -o '/[^ ]*\.so[^ ]*' | awk '!seen[$0]++' | wh
by internet_points 2y ago
Here's a .deb version; only running debsums once per package name. Errors will go to stderr:
sudo lsof | grep -o '/[^ ]*\.so[^ ]*' | awk '!seen[$0]++' | while read -r path; do
if p=$(dpkg -S "$path");then
cut -f1 -d: <<<"$p"
fi
done | awk '!seen[$0]++' | xargs -n1 debsums -s
(But is there a hard rule that says a loaded library has to be named .so, or show up as .so for lsof? I'm sure there's ways to avoid the above detection.)
- Y_Y 2y ago> But is there a hard rule that says a loaded library has to be named .so, or show up as .so for lsof? No, yes(-ish) Filenames are just a convention and not necessarily enforced. lsof will really list every file the kernel thinks has a handle held by an active process, but depending on your threat model I think you could get around this. For example you could copy the malicious code into memory and close the file, or use your preload to modify the behaviour of lsof itself (or debsums). Anyway debsums is a great tool. I'd have used a command similar to yours, though maybe run debsums first, use `file` to filter dynamic libraries and then check which of those have been recently accessed from disk.
- tenthirtyam 2y agoThis didn't quite work for me - dpkg complained about "no path found matching..." for every library. I replaced the "$path" in the dpkg command with "${path##*/}" to just match the library name. Further inspection showed my package manager installed libraries to /lib (a soft link to /usr/lib/) but lsof returns files in /usr/lib. Other than that it seems to work - i.e. no alarming output. :-)