NixOSと再現可能なビルドによって検出された xz バックドア

• 2024年3月、Linuxディストリビューションでソース tarball の展開に使われる xz ソフトウェアにバックドアが発見された。
• このバックドアは、悪意あるメンテナー Jia Tan によって3年にわたり密かに仕込まれていた。
• この事件はリモートコード実行を可能にするため影響が大きく、発見も非常に困難だった。
• Microsoft の Postgres 開発者である Andres Freund が性能低下を調査していた際に偶然発見し、大惨事を回避できた。

攻撃の仕組み

• バックドアは ssh プログラムをハイジャックし、リモートコード実行を可能にする。
• RSA_public_decrypt 関数を書き換え、特定の RSA キーでログインした際に攻撃者が任意のコマンドを実行できるようにする。
• 主な構成要素は2つある。
  1. xz のビルドプロセスの一部として悪意あるオブジェクトファイルをインストールするスクリプト。
  2. RSA_public_decrypt 関数をフックする手順。

1. 悪意あるオブジェクトファイルのインストールスクリプト

• 悪意あるオブジェクトファイルは、xz の git リポジトリ内のテストファイルに隠されていた。
• バックドアは、メンテナーが提供したリリース tarball でのみ有効化された。

2. RSA_public_decrypt 関数のフック手順

• 動的ロード時に実行されるコードを強制的に走らせるため、glibc の ifunc 機能が使われた。
• ssh の実行時に libsystemd と liblzma がロードされ、その過程でバックドアが任意のコードを実行する。

xz の惨事を避けるための方法

• オープンソースソフトウェアの信頼性を高めるには、社会的な問題と技術的な問題の両方に取り組む必要がある。
• ソフトウェアサプライチェーンのセキュリティプロセスを改善しなければならない。

信頼できるソースからソフトウェアをビルドする

• 多くのディストリビューションがメンテナー提供の tarball を使って xz をビルドしていたため、攻撃は効果的だった。
• 可能な限り、最も信頼できるソースからソフトウェアをビルドすべきである。

状況が許すなら…

• NixOS は関数型パッケージ管理モデルに基づくディストリビューションであり、各パッケージは Nix という関数型プログラミング言語で表現される。
• NixOS には、GitHub で自動生成されたソースアーカイブを利用する文化がある。

信頼できないリリース tarball に信頼を構築する

• NixOS はブートストラップ段階で、メンテナー提供の tarball を使用する必要があった。
• ソフトウェアサプライチェーンのセキュリティを強化するため、特定の保護措置を整える必要がある。

1. ソースの比較

• ディストリビューションで使うソース tarball が GitHub のものと同一か確認することが重要である。
• ただし、リリース tarball がソースと異なることはよくあり、それ自体は問題ではない。

2. ビット単位の再現性を活用する

• 再現可能なビルド とは、同じ条件で2回ビルドしたときに同一の成果物を生成するというソフトウェアプロジェクトの性質である。
• ビット単位の再現性によって、信頼できないメンテナー提供 tarball に対する信頼を構築できる。

結論

• xz バックドア事件は、オープンソースソフトウェアのサプライチェーンセキュリティの重要性を改めて示した。
• NixOS のようなシステムは、再現可能なビルドを通じてセキュリティを強化できる。

[GN⁺]

Hacker Newsの意見

• NixOSと再現可能ビルドは xz バックドアを検出できなかった。NixOS は悪意ある xz ビルドを配布したが、NixOS を標的にしたものではなかったため問題は起きなかった

  • NixOS 開発者は、バックドアが明らかになった際に悪意ある xz バージョンがユーザーに配布されていたのを見て驚いた
  • 理論と現実は異なり、xz が成立した理由は技術的脆弱性ではなく「現実世界」の問題だった。ソフトウェアで現実世界をパッチできないことを認識するのは難しい

• 筆者は今回の事件だけに集中しているように見える。Jiatan 事件は単一の事例であり、他のシナリオでも防御は失敗しうる

  • NixOS ユーザーとして、NixOS がこれを捕捉できなかった可能性は高いと思う。証拠がないなら NixOS を信頼するのは愚かだ

• xz バックドアは RedHat と Debian を標的にしていたため、NixOS は無関係だった。皮肉なことに、バックドアは Microsoft の社員によって発見された

• 記事では、ディストリビューションは従来のインストール用 tarball ではなく、VCS（例: Github）から直接ソースコードを取得すべきだと述べている

  • しかし悪意あるメンテナーは、ソースコードリポジトリに直接バイナリ blob を追加できる
  • 筆者は Github がコードを検証するかのように信頼できると示唆しているが、実際には Github はコードを検証しない

• NixOS が防げた可能性のある事件に注目するなら、CrowdStrike 事件に注目すべきだ。昨日の設定で起動できていれば、問題の大半を緩和できたはずだ

• NixOS はすべてをソースからコンパイルし、使われたソースが改ざんされていないことを暗号学的に検証し、パッケージ間のバージョン依存関係を持つ。Debian にも再現可能ビルドがある

  • 問題は、ビルドシステムがソースからビルドする前に事前コンパイル済みのオブジェクトファイルを削除しなかったことだ。ソースコードを誰も確認しなければバックドアを追加でき、NixOS や他のディストリビューションでもそれを防げない

• 「できたはずだ」というのは、証明されていないことを意味するが、実際には彼らはそれを配布していた

• 優れた説明的分析。タイトルは誤解を招きやすく、おそらく「技術的には正確」だが、「バックドア付き」という意味に取るのが最も自然だ

  • ビルドマネージャーツールの必要性と活用を強調しており、ビルド過程でどのファイルがどのファイルに影響したかの因果追跡グラフを明示的に作り、そのグラフを強制するか、以前の追跡グラフからの逸脱を報告する方法を構築すべきだ

• Jia Tan の PR が承認されていれば、悪意あるアーティファクトは tarball と同じように簡単に Github リリースへ入れられただろう。Github リリースがセキュリティ緩和策だという考えは理解しがたい

• リリース tarball がソースと異なるという点

  • メンテナーが提供した tarball が元のソースコードから正直に生成されていたなら、どうして別バージョンなどが問題になるのか理解しにくい
  • 生成された tarball はソースコード自体から生成できるようにし、何も除外せず、git add & commit すべきだ。この場合でもコミット履歴を確認する必要があり、肉眼では無害に見えたのだから、どう検証できるのか疑問だ
  • 保守された tarball が所有者のソースコードから生成され、Github に存在しないなら問題になる

• 毒入りのテストファイルを push した以上の問題があったが、Nix がこれをどう防げたのか理解しにくい

  • 著名なプロジェクトでリーダーが変わったなら、コミットを注意深く見て、誰がリーダーなのか確認すべきだろう

• 記事を誤読したのか、何か見落としているのか気になる