このコマンドは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が指摘したように、Debianのよう.so
に、これらのファイルの大部分またはすべてが欠陥のあるコアファイルにリンクされる可能性があるため、これは欠陥ではない可能性があります。libc6
特定のOS/ディストリビューションが必要な場合は、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