世界中をほぼ感染させかけた xz Utils バックドアについてわかっていること

 (arstechnica.com)
3 ポイント 投稿者 GN⁺ 2024-04-02 | 1件のコメント | WhatsAppで共有

xz Utils バックドア事態: 世界中をほぼ感染させかけた事件についてわかっていること

  • xz Utils は、Linux をはじめ、ほぼすべての Unix 系オペレーティングシステムにインストールされているデータ圧縮ユーティリティ。
  • このソフトウェアに悪意あるアップデートが行われ、バックドアが仕込まれかけた事件が発生した。
  • Microsoft の開発者がこのバックドアを発見して公表したことで、Debian や Red Hat といった主要な Linux ディストリビューションに取り込まれる直前の危機が防がれた。

バックドアはどのように動作するのか?

  • バージョン 5.6.0 と 5.6.1 に追加された悪意あるコードは、sshd、つまり SSH 接続のための実行ファイルを改変する。
  • 特定の暗号鍵を持つ人物は、SSH ログイン証明書にコードを隠してアップロードし、バックドアがインストールされたデバイス上で実行できる。
  • 実際にどのようなコードがアップロードされたのかは不明だが、理論上は暗号鍵の窃取やマルウェアのインストールなど、さまざまな行為が可能となる。

バックドアが仕込まれた経路

  • バックドアは数年かけて作られたように見える。
  • 2021年、JiaT75 というユーザーが初めてオープンソースプロジェクトに貢献した。
  • 2023年1月、JiaT75 は xz Utils に最初の貢献を行い、その後 Jia Tan という名前で次第に多くの役割を担うようになった。
  • Tan は oss-fuzz プロジェクトで Collins の連絡先情報を自分のものに置き換え、テスト中に ifunc 機能を無効化するよう要請した。
  • これらの変更は、Tan が xz Utils に悪意ある変更を加えた際に、それを検知することを妨げた。

影響を受けたディストリビューション

  • Fedora Rawhide、Fedora 41、Debian testing/unstable/experimental、openSUSE Tumbleweed および MicroOS、Kali Linux などが、バックドアが仕込まれた xz バージョンを含んでいた。

GN⁺の意見

  • この事件はオープンソースエコシステムのセキュリティ上の脆弱性を露呈し、開発者コミュニティの警戒心を高める契機となった。
  • バックドアが仕込まれたソフトウェアが広く使われているだけに、今回の事態は Linux ユーザーや管理者に、迅速なアップデートとセキュリティ点検の重要性を改めて認識させた。
  • 類似の事例として SolarWinds ハッキング事件があり、その事件もサプライチェーン攻撃の危険性を示した。
  • オープンソースプロジェクトに貢献する開発者の身元を検証し、コードレビューの過程を強化する必要がある。
  • 今回の事件をきっかけに、セキュリティ監査と脆弱性検知ツールの重要性がさらに高まると見られる。

関連記事

1件のコメント

 
GN⁺ 2024-04-02
Hacker Newsのコメント

  • OpenSSHは最も人気のあるsshd実装だが、liblzmaライブラリにはリンクしていない。ただし、Debianやそのほか多くのLinuxディストリビューションは、sshdをsystemdに接続するパッチを追加している。systemdはliblzmaにリンクしているため、xz Utilsがsshdに影響を与え得る。

  • Xzはオープンソースの圧縮プログラムでありライブラリでもあり、圧縮データを扱う独自のプログラムを書くのに役立つ。OpenSSHを含む多くのプログラムで使われている。

  • GNUのbinutilsもliblzmaにリンクしており、OpenSSHよりさらに広く使われている。多くの場合、binutilsはOpenSSHやsshdが動作するOSなどのコンパイルに使われる。これは、悪意ある行為者がオープンソースソフトウェアの深部に入り込むための格好のプロジェクトを選んだことを示唆している。

  • XZプロジェクトの長期的な安定性を支えるため、より多くのテスト作成に役立つ標準化されたテストフレームワークの採用が目標とされている。まだテストされていない機能が多いため、こうしたテストは有用になるはずだ。

  • RSA_public_decrypt関数にフックできるリンキング機構についての議論はあまりなかった。プロセス分離などで実現できることについての議論は多かったが、その関数呼び出しのリダイレクト自体については少なかった。重要なコンポーネントを信頼レイヤー方式で結び付ける方法を確立できるのかという疑問が出ている。

  • 世界を「ほぼ」感染させたと言うが、実際にはArch、Gentoo、openSUSE Tumbleweedのような人気Linuxディストリビューションが、数週間にわたってバックドア入りの状態で配布されていた。Tumbleweedでは確実に動作していたため、「ほぼ」という表現は不適切だ。

  • 今後12か月以内に類似事例が見つかるだろうという予測。保守担当者たちが互いの過去のコミットを疑い始めることから始まるだろう。

  • この事件から得た個人的な教訓:

    • ソースリポジトリとは異なるコードを含むソース配布tarballは良くない。このやり方から脱却すべきだ。
    • 自動生成されたアーティファクトは常にコミットされるべきだ。
    • コードレビュー中に誰もが流し見してしまう自動生成アーティファクトは問題になり得る。この種のファイルがリポジトリにあるなら、誰かに改ざんされていないことを確認する自動テストが必要だ。
    • autotoolsとautotools文化は良くない。
    • libsystemdはエコシステムに問題を引き起こす。systemdを批判する人々はしばしば無視されるが、systemdは大きく複雑で依存関係も多く、ほとんどのプログラムはその一部しか使わない。
    • コード再利用は常に善であり、小さな機能のために巨大なライブラリへ依存するのが良いという文化は誤っている。依存関係は保守負担とセキュリティリスクをもたらすため、機能性とのバランスを取る必要がある。
    • ディストリビューションの保守担当者がパッケージに大幅なパッチを当てることは問題になり得る。実際に面倒を見る人のいない、広く使われる事実上のフォークを生み出してしまう。
    • 開発者がOSS作業を金銭的に継続できるようにする必要がある。liblzmaとxz-utilsは何千万ものインストールがある一方で、メンテナはメンタルヘルスの問題を抱えた単独の保守担当者しかいない。
    • コードレビューと保守担当者の交代は、現在では地政学的な考慮も踏まえる必要がある。

  • 問題を発見した人物がAzure Postgresで働くMicrosoftのエンジニアだったことへの感謝。これでAzureが好きになった。

  • xzの元の保守担当者はJia Tanに責任を引き継いだが、実際には会ったことも電話で話したこともなかった可能性がある。EmailやGitHubだけでやり取りするのは一般的なのかという疑問が出ている。この一件を受けて、今後はオープンソースプロジェクトの保守担当者がより慎重になるだろう。

  • このバックドアは早期に発見されたと考えられている一方で、すでに目的を達していた可能性もある。特にKaliやDebianのようなローリングリリース系ディストリビューションを使う開発者が標的だったなら、なおさらだ。

  • xz Utilsの長年の保守担当者であるLasse Collinが、ソフトウェアを頻繁に、あるいは十分な速さで更新していなかったという主張は誤りだったことが示唆されている.