2024年3月、圧縮ツール「XZ Utils」のバージョン5.6.0と5.6.1に、悪意のあるコードが仕込まれていたことが発覚しました（CVE-2024-3094）。発見が半年遅れていれば、多くのLinuxサーバーのSSHが乗っ取られていた可能性がある事件です。「自分のサーバーは大丈夫」と言い切るには、パッケージの中身が配布元と一致しているか、共有ライブラリが勝手に差し替えられていないかを、自分の手で確認する必要があります。この記事では、Ubuntu/Debian環境でdebsums -cによるパッケージ改ざん検知と、/etc/ld.so.preload・lddによる不審な共有ライブラリ注入の点検方法を、コマンドと出力例つきで解説します。
XZ Utilsバックドア事件(CVE-2024-3094)から学ぶべきこと
まず何が起きたのかを短く整理します。攻撃者は数年かけてXZ Utilsのメンテナーとして信頼を築き、ビルドスクリプトの中に悪意のあるコードを仕込みました。これがコンパイルされると、圧縮ライブラリliblzmaに不正な処理が混入し、一部のディストリビューションではSSHサーバー(sshd)がこのliblzmaを間接的に読み込む構成になっていたため、SSH経由での不正アクセスにつながる恐れがありました。発覚したのはPostgreSQLの開発者Andres Freund氏が、SSH接続がわずかに遅い・CPU使用率がおかしいという些細な違和感に気づいたことがきっかけです。
この事件が示す教訓はシンプルです。「パッケージ管理システム経由でインストールしたから安全」とは言い切れないということです。配布元のビルドプロセス自体が汚染されるケースがある以上、利用者側でも「今インストールされているファイルは、本来配布されるべきものと一致しているか」を点検する手段を持っておく必要があります。攻撃の再現手順はこの記事では扱いません。ここから先は、あくまで自分のサーバーを守る側の点検方法です。
なお、影響を受けたバージョンに該当するかどうかの基本的な確認は、パッケージのバージョン管理がベースになります。ソフトウェアのバージョンとセキュリティ情報の照合については sudo/sshバージョン確認2026年9月版｜USN照合で脆弱性点検 でも扱っているので、あわせて確認してください。
debsums -cでパッケージ改ざんを点検する(Ubuntu/Debian共通)
debsumsとは何を見ているコマンドか
debsumsは、Debian系パッケージ(.deb)に記録されているファイルのチェックサム(MD5)と、実際にディスク上にあるファイルの中身を比較するツールです。パッケージインストール直後の「本来の状態」と、今の状態を突き合わせることで、パッケージ管理を経由しない改ざんを検出できます。
インストールと実行
標準ではインストールされていないことが多いので、まず導入します(sudoが必要・パッケージを1つ追加するだけで既存の設定は変更しません)。
sudo apt update
sudo apt install debsums導入したら、全パッケージのファイルを検証します(読み取り専用の点検で、システムには一切変更を加えません)。
sudo debsums -c出力の見方
出力 | 意味 | 判断 |
|---|---|---|
何も表示されない | 全ファイルがパッケージの記録と一致 | 正常 |
ファイルパスが1行以上表示される | そのファイルの中身が配布時と異なる | 要調査 |
「debsums: no md5sums for パッケージ名」という警告 | そのパッケージ自体がチェックサム情報を持っていない | 点検対象外(異常ではないが、そのパッケージは検証できていないと認識する) |
不一致が出た場合の実行例(架空の値です):
$ sudo debsums -c
/usr/lib/x86_64-linux-gnu/liblzma.so.5.4.5この場合、まず「自分で設定ファイルを直接編集した」「手動でビルドしたものを上書きした」などの心当たりがないか確認します。心当たりがなければ、次の章で解説するldd・/etc/ld.so.preloadの確認とあわせて調べます。
/etc/ld.so.preloadで強制読み込みライブラリを確認する
ld.so.preloadとは何を見ているファイルか
/etc/ld.so.preloadは、ここに書かれた共有ライブラリを、システム上で動くほぼ全てのプログラムに強制的に読み込ませる設定ファイルです。用途は限られていて、通常の環境では存在しないか、存在しても空であることがほとんどです。ここに不審なパスが書き込まれると、正規のコマンド(ls・ps・sshなど)を実行するたびに、意図しないコードが一緒に読み込まれる状態になります。過去に見つかったLinux向けの侵入ツールの中には、この仕組みを悪用して自分の存在を隠すものがあったことが知られています(具体的な手口はここでは扱いません)。
確認コマンド
sudo不要・読み取りだけのコマンドです。
cat /etc/ld.so.preload出力の見方
- 「No such file or directory」と表示される→ファイル自体が存在しない。多くの環境ではこれが正常な状態です。
- 何も表示されず終了する→ファイルは存在するが空。これも正常です。
- パスが1行以上表示される→そのライブラリが全プロセスに強制読み込みされています。ここが要注意です。
パスが表示された場合の実行例(架空の値です):
$ cat /etc/ld.so.preload
/usr/lib/x86_64-linux-gnu/libcheck.so表示された場合は、そのファイルがどのパッケージに属するかを確認します。
dpkg -S /usr/lib/x86_64-linux-gnu/libcheck.so「どのパッケージにも属していません」と返ってくる場合や、心当たりのないパッケージから来ている場合は、勝手に置かれたファイルである可能性が高く、次の章の対応に進みます。逆に、自分で意図してセキュリティ監視ツール(sudo実行の監査など)を導入していて、そのツールのドキュメントに書かれている場合は正常な用途のこともあるので、導入した記憶があるかをまず思い出してください。
lddでsshdなど主要コマンドの共有ライブラリを確認する
lddとは何を見ているコマンドか
lddは、実行ファイルが起動時にどの共有ライブラリを、どのパスから読み込むかを表示するコマンドです。XZ Utils事件のように、ライブラリ自体の中身は差し替えられていても、通常のパッケージ確認だけでは気づきにくいケースがあるため、実際にどこから読み込まれているかを直接見ておくと安心材料になります。
確認コマンド
sudo不要・読み取りだけのコマンドです。SSHサーバーの実行ファイルを例にします。
ldd /usr/sbin/sshd出力例(架空の値です):
linux-vdso.so.1 (0x00007ffd...)
libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f2a...)
liblzma.so.5 => /usr/lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f2a...)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f2a...)出力の見方
- 各ライブラリのパスが
/lib/や/usr/lib/配下の標準的な場所になっているか。/tmp/や一般ユーザーのホームディレクトリ(例:/home/username/.local/lib/)を指している行があれば、そこが差し替えの入口になっている可能性があります。 - 「=> not found」と表示される行がないか。本来あるはずのライブラリが見つからない状態は、ライブラリが移動・削除された、または想定外の場所に置かれている兆候です。
- 気になるパスが出たら、そのパスに対して
dpkg -S パスを実行し、正規のパッケージが所有しているかを確認します。
注意点:manページにも明記されていますが、lddは仕組み上、対象の実行ファイルを一部実行してライブラリを解決するため、出所が全く分からない実行ファイルに対して使うのは安全ではありません。今回のようにOSに標準で入っているsshd・bashなどのコマンドを確認する分には問題ありませんが、ダウンロードしてきた得体の知れないファイルを調べたい場合は、objdump -p ファイル名 | grep NEEDEDのように実行を伴わない方法を使ってください。
不要なカーネルモジュールが仕込まれていないかという、もう一段低いレイヤーの点検については lsmodで不要カーネルモジュール点検2026年9月版 も参考にしてください。共有ライブラリの点検とあわせて行うことで、ユーザー空間・カーネル空間の両方をカバーできます。
異常が見つかったときの対応と、これだけでは防げないこと
debsumsで不一致が出たとき
- まず、そのパッケージを再インストールして直るか試します(設定ファイルには影響しません)。
sudo apt install --reinstall パッケージ名 - 再インストールで直った場合は、単なる手違いや過去の手動編集だった可能性が高いです。
- 再インストールしても同じ不一致が出る、または身に覚えのないファイルが対象の場合は、その端末をネットワークから切り離し、他の端末から状況を調べる方針に切り替えてください。改ざんされたファイルを起点に別の場所へ広がっている可能性があるため、その端末上で追加の調査コマンドを実行し続けるのはおすすめしません。
ld.so.preloadに見覚えのない記載があったとき
ファイルの中身をすぐ削除せず、まずは記録に残してください(あとで調査する際の手がかりになります)。中身が正規のパッケージに属さないと分かった場合は、debsumsの不一致時と同様に、その端末をネットワークから切り離し、バックアップからの復元や再構築を検討してください。この仕組みは全プロセスに影響する強力な手口なので、見つかった場合は「該当ファイルだけ消して終わり」にはしないことが重要です。
この点検だけでは防げないこと
debsumsはパッケージ管理システム経由で入ったファイルしか検証できません。パッケージ管理を経由しない手動インストールのソフトウェアは対象外です。また、これらのコマンドはあくまで「今の状態」のスナップショットなので、定期的に実行しなければ変化に気づけません。多層防御の一環として、AppArmorによるプロセスの権限制限を点検する aa-statusでAppArmor点検2026年9月版 もあわせて確認しておくと、万一の被害を小さく抑えられます。
XZ Utilsバックドア事件は、パッケージ管理という信頼の仕組みそのものが汚染されうることを示した事例でした。debsums -cでインストール済みファイルの改ざんを、/etc/ld.so.preloadとlddで共有ライブラリの読み込み経路を、それぞれ読み取り専用のコマンドで点検できます。いずれもシステムに変更を加えるものではなく、異常が見つかったときだけ次の対応(再インストール・ネットワーク切断・調査)に進む形なので、まずは自分のサーバーで一度実行し、正常時の出力を確認しておくことをおすすめします。