如何使用库包检测正在运行的进程?

如何使用库包检测正在运行的进程?

此命令正在使用 glibc 循环检测当前正在运行的进程:

lsof | grep libc | awk '{print $2}' | sort | uniq

我发现它非常烦人,因为/libc/不仅匹配libc,而且在我的系统上匹配:

/lib/x86_64-linux-gnu/libcap.so.2.24
/lib/x86_64-linux-gnu/libcgmanager.so.0.0.0
/lib/x86_64-linux-gnu/libcom_err.so.2.1
/lib/x86_64-linux-gnu/libcrypt-2.19.so
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
/usr/lib/libcamel-1.2.so.45.0.0
/usr/lib/unity-settings-daemon-1.0/libcolor.so
/usr/lib/unity-settings-daemon-1.0/libcursor.so
/usr/lib/x86_64-linux-gnu/colord-plugins/libcd_plugin_camera.so
/usr/lib/x86_64-linux-gnu/colord-plugins/libcd_plugin_scanner.so
/usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libcanberra-gtk3-module.so
/usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2.11301.0
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11301.0
/usr/lib/x86_64-linux-gnu/libcanberra-0.30/libcanberra-pulse.so
/usr/lib/x86_64-linux-gnu/libcanberra-gtk3.so.0.1.9
/usr/lib/x86_64-linux-gnu/libcanberra.so.0.2.5
/usr/lib/x86_64-linux-gnu/libcap-ng.so.0.0.0
/usr/lib/x86_64-linux-gnu/libck-connector.so.0.0.0
/usr/lib/x86_64-linux-gnu/libcolordprivate.so.1.0.23
/usr/lib/x86_64-linux-gnu/libcolord.so.1.0.23
/usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1
/usr/lib/x86_64-linux-gnu/libcupsmime.so.1
/usr/lib/x86_64-linux-gnu/libcups.so.2
/usr/lib/x86_64-linux-gnu/samba/libcliauth.so.0
/usr/lib/x86_64-linux-gnu/samba/libcli_cldap.so.0
/usr/lib/x86_64-linux-gnu/samba/libcli-ldap-common.so.0
/usr/lib/x86_64-linux-gnu/samba/libcli-nbt.so.0
/usr/lib/x86_64-linux-gnu/samba/libcli_smb_common.so.0
/usr/lib/x86_64-linux-gnu/samba/libcli_spoolss.so.0
/usr/lib/x86_64-linux-gnu/samba/liblibcli_lsa3.so.0
/usr/lib/x86_64-linux-gnu/samba/liblibcli_netlogon3.so.0

我知道libc几乎所有东西都使用它,但我想改进这个命令。考虑它在其他库中的应用。我怎样才能做到这一点?

在我看来,这种方法的缺陷是提供的包libc可能包含大量其他共享库文件(所有这些文件可能都包含在库名称的总括术语中,例如glibc、 或libboost-python)。使用单词边界或-标记结尾libc并不能真正解决这个问题。正如 Braiam 指出的那样,这可能不是一个缺陷,因为许多或所有这些.so文件可能链接到该缺陷所在的核心文件,就像libc6Debian 上的情况一样。

如果需要特定的操作系统/发行版,请假设 Debian Linux。

同样令人烦恼的是,该命令可能会被压缩为lsof | awk '/libc/{print $2}' | sort -u.

答案1

这是一种迂回且极其不准确的方法。您知道库文件的位置,因此不需要使用启发式方法来匹配它,您可以搜索确切的路径。

有一种非常简单的方法可以列出打开文件的进程:

fuser /lib/x86_64-linux-gnu/libc.so.6

然而,这列出了具有当前的打开文件的版本,即使用库的新副本的进程。如果要列出具有已删除副本的进程,可以使用lsof,但要搜索确切的路径。限制lsof包含已删除文件的文件系统以提高性能(并可能避免阻塞,例如暂时无法访问的网络文件系统)。

lsof -o / | awk '$4 == "DEL" && $8 == "/lib/x86_64-linux-gnu/libc-2.13.so" {print $2}'

如果升级后的包包含多个库并且您想要检测任何库,请列出包中的所有库文件。这是一种以编程方式执行此操作的方法(对于 Debian 软件包,根据您的发行版进行调整,例如rpm -ql glibc在 Red Hat 上)。

lsof -o / | awk '
   BEGIN {
       while (("dpkg -L libc6:amd64 | grep \\\\.so\\$" | getline) > 0)
           libs[$0] = 1
   }
   $4 == "DEL" && $8 in libs {print $2}'

答案2

grep -w libc在本例中使用。您还可以用于ldd静态分析。

为了进行匹配,您需要使用正则表达式。grep '/libc-'在这里工作,但如果你想找到像 libcan 这样的东西,你可以使用类似的东西'/libcan\>',其中\>强制在词尾进行匹配。

答案3

测试 GHOST 漏洞(我们之前发现的所有内容):

wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c
gcc gistfile1.c -o CVE-2015-0235
./CVE-2015-0235

来源

相关内容