XZバックドア事件: 初期分析結果

 (securelist.com)
2 ポイント 投稿者 GN⁺ 2024-04-13 | 1件のコメント | WhatsAppで共有
  • XZ Utils/liblzma バックドアは2024年3月29日にOpenwall OSS-securityメーリングリストで公開され、systemdベースのディストリビューションのOpenSSHサーバー sshd にリモートコード実行能力を仕込むことが攻撃者の最終目標だった可能性が高い
  • 感染チェーンはXZリポジトリのテストファイルとビルドインフラを利用した 多段階挿入 で構成され、build-to-host.m4、bad-3-corrupt_lzma2.xz、good-large_compressed.lzma を経て、悪性オブジェクトファイルがビルド中に liblzma へリンクされる
  • バックドアを含む XZ 5.6.0 と 5.6.1 は一部主要ベンダーのベータ版・実験版ビルドとして配布され、CVE-2024-3094 は重大度 10点 に指定された
  • バイナリバックドアはGLIBCの IFUNC と cpuid 呼び出し経路を悪用してロードされ、その後 OpenSSL/libcrypto 関連関数をフックして感染マシンへの接続を監視しようとする
  • 悪性コードは /usr/bin/sshd の実行有無とキルスイッチ環境変数を確認し、trieベースの文字列処理・動的シンボル解決・rtdl-audit ランタイムパッチによって分析と検出を困難にする

事件の概要と影響範囲

  • 2024年3月29日、Openwall OSS-securityメーリングリストの メッセージ を通じて XZバックドア の発見が公開された
  • XZ は複数の主要 Linux ディストリビューションに統合されている 圧縮ユーティリティ である
  • リスクの核心は、バックドアを含む liblzma が一部の systemd ベースのディストリビューションで OpenSSH サーバープロセス sshd と接続され得る点にある
    • Ubuntu、Debian、RedHat/Fedora Linux は OpenSSH が systemd 機能を使うようにパッチされており、このライブラリに依存している
    • Arch Linux と Gentoo は影響を受けないと整理されている
  • 攻撃者の最終目標は、他者が利用できない sshd のリモートコード実行 機能を埋め込むことだった可能性が高い
  • 単一の悪性パッチ、偽パッケージ、タイポスクワッティングパッケージ中心の他のサプライチェーン攻撃と異なり、この事件は 世界中の SSH サーバー侵害にほぼ成功しかけた多段階作戦 に近い

バックドアが仕込まれた方法

  • liblzma バックドアは、ビルド過程とテストファイルを併用して二層で挿入された
    • 最終パッケージを生成する ビルドインフラのソースコード が build-to-host.m4 の追加によって改変された
    • テストケースファイル内に隠されたスクリプトとバイナリ構成要素がビルド中に抽出された
  • 感染フローは3つのファイルを中心に進行した
    • build-to-host.m4: 次段階スクリプトを抽出するビルドスクリプト
    • bad-3-corrupt_lzma2.xz: シェルスクリプトが隠されたテストファイル
    • good-large_compressed.lzma: 悪性バイナリオブジェクトが隠されたテストファイル
  • 抽出された悪性バイナリ構成要素はコンパイル過程で正常なライブラリとリンクされ、Linux リポジトリへ渡され得た
  • 主要ベンダーはこの悪性構成要素を ベータ版および実験版ビルド に含めて配布した
  • XZ Utils 侵害には CVE-2024-3094 が割り当てられ、重大度は最大値の 10点 である

主なタイムライン

  • 2024年1月19日: 新しいメンテナー jiaT75 が XZ ウェブサイトを GitHub Pages に移行
  • 2024年2月15日: build-to-host.m4 が .gitignore に追加
  • 2024年2月23日: 悪性スクリプト段階を含む2つの「テストファイル」が追加
  • 2024年2月24日: XZ 5.6.0 がリリース
  • 2024年2月26日: CMakeLists.txt に Landlock セキュリティ機能を妨げるコミットが入る
  • 2024年3月4日: バックドアが Valgrind 関連の問題を引き起こす
  • 2024年3月9日: 2つのテストファイルが更新され、CRC 関数が修正され、Valgrind 問題が「修正」される
  • 2024年3月9日: XZ 5.6.1 がリリース
  • 2024年3月28日: バグが発見され、Debian と RedHat に通知
  • 2024年3月28日: Debian が XZ 5.6.1 を 5.4.5-0.2 バージョンにロールバック
  • 2024年3月29日: OSS-security メーリングリストに公開メールが投稿される
  • 2024年3月29日: RedHat が Fedora Rawhide と Fedora Linux 40 beta にバックドア入り XZ が配布されたと確認
  • 2024年3月30日: Debian がビルドを停止し、再ビルド手続きを開始
  • 2024年4月2日: XZ のメイン開発者がバックドア事件を認める

感染チェーンの3段階

  • 1段階: 改変された build-to-host.m4

    • XZ の公式 GitHub リポジトリのリリースには悪性テストファイルが含まれていたが、それらのファイルが実行される機会がなく、当初は無害だった
    • 感染をブートストラップする悪性コードは、jiaT75 が管理していた xz[.]tukaani.org で提供されたリリースに含まれていたようだ
    • ほとんどのディストリビューションはこの URL を使用しており、ダウンロードされたリリースには悪性コードを含む build-to-host.m4 ファイルが含まれていた
    • build-to-host.m4 はビルド過程で実行され、bad-3-corrupt_lzma2.xz の「壊れた」データを tr で修正した後、xz -d で展開する
    • 展開結果には、後で /bin/bash によって実行される シェルスクリプト が含まれている

  • 2段階: 挿入されたシェルスクリプト

    • 悪性 .m4 ファイルが挿入したスクリプトは、Linux マシン上で実行中か、意図されたビルドプロセス内で実行中かを確認する
    • 次段階の実行には good-large_compressed.lzma が使われる
    • このファイルは XZ で正常に圧縮されているが、展開データ内に ジャンクデータ が含まれている
    • スクリプトは head パイプラインを eval で実行してデータを抽出する
    • 各 head コマンドは次の 1024 バイトを無視するか、次の 2048 バイトまたは 724 バイトを抽出する
    • 合計 33,492バイト が抽出される
    • tail はファイル末尾の 31,265バイト を保持し、それ以外を無視する
    • その後 tr で基本的な置換を適用して難読化を解除し、2つ目の XZ コマンドが変換済みバイト列を raw lzma ストリームとして展開し、その結果をシェルに渡す

  • 3段階: バックドアオブジェクトの抽出

    • 最終段階のシェルスクリプトは、想定環境で実行中かどうかを複数の条件で確認する
    • プロジェクトが IFUNC を使うよう構成されているかを確認する
    • GCC でコンパイルされているかを確認する
    • その後、スクリプトが使用する特定ファイルがプロジェクト内に存在するかを確認する
    • この段階では good-large_compressed.lzma の別オフセットに隠された オブジェクトファイル を抽出する
    • 抽出手順では複数のコマンドを順次実行し、各コマンドの出力を次のコマンドの入力へ渡す
    • XZ ツールで good-large_compressed.lzma を抽出する
    • eval $i と複数の head 呼び出しを使用する
    • RC4 に似たカスタムアルゴリズムでバイナリデータを復号する
    • 復号された圧縮ファイルを再び XZ で抽出する
    • 先頭の一部バイトを削除した後、結果を liblzma_la-crc64-fast.o として保存する
    • 最後にスクリプトは liblzma の crc_x86_clmul.h ファイル内の is_arch_extension_supported 関数を修正する
    • __get_cpuid 呼び出しを _get_cpuid に変更し、アンダースコアを1つ削除する
    • この変更により、バックドアオブジェクトをライブラリへリンクできるようになる

バイナリバックドアのロード方法

  • 元の XZ コードには CRC 計算用の特殊関数 lzma_crc32 と lzma_crc64 がある
  • これら2つの関数は ELF シンボルテーブルで GLIBC の IFUNC 型として格納されている
    • IFUNC は、動的リンカーが共有ライブラリをロードする際に使用する関数を動的に選択できるようにする
    • XZ は、最新プロセッサ機能である CLMUL、SSSE3、SSE4.1 を確認したうえで最適化された CRC 関数を使うか決めるため、この機能を利用している
  • プロセッサ機能の確認には cpuid 命令が必要であり、GLIBC が提供する __get_cpuid ラッパーが呼び出される
  • 悪性スクリプトが __get_cpuid を _get_cpuid に変更したことで、コード呼び出しはバックドアオブジェクトファイル内の _get_cpuid シンボル に結び付けられる
  • 初期バックドアコードは lzma_crc32 と lzma_crc64 が同じ改変関数 _get_cpuid を使うため2回呼び出される
    • 単純なカウンターで既に実行済みかを確認する
    • lzma_crc64 IFUNC が _get_cpuid を呼び出し、カウンター値が 1 の場合に最終エントリポイントへリダイレクトする段階が始まる

ランタイム動作とフック対象

  • バックドアは、実行中プロセスの重要情報を保持する構造体を初期化する
  • ハードコードされたオフセットで Global Offset Table(GOT) のアドレスを見つけ、その中の cpuid ポインタを探す
  • その後ポインタをメインの悪性関数に置き換え、cpuid を呼び出すかのように 悪性関数を呼び出す
  • 主な目的は、感染したマシンに入ってくる接続を監視できるよう特定の関数をフックすることにある
  • 標的関数は libcrypto に関連する
    • RSA_public_decrypt: 秘密鍵で署名された暗号文を復号する際に使用される
    • EVP_PKEY_set1_RSA: 特定コンテキストの RSA 鍵を設定する際に使用される
      • 最新の SSH サーバーバージョンには存在しないが、独立した SSH 鍵生成ツールでは使用される
    • RSA_get0_key: RSA 鍵を取得する際に使用される
  • フック過程では複数の内部構造体へのアクセスとプロセス別構造体の操作が必要であり、悪性コードは分析回避のためのチェックも併せて行う

実行環境の確認と分析回避手法

  • sshd とキルスイッチの確認

    • バックドアはまず、シンボルアドレスを動的に解決する ld-linux 動的リンカー を解析する
    • 現在の実行環境が条件に合うかを確認する
    • 現在のプロセスが /usr/bin/sshd かを確認する
    • キルスイッチが存在するかを確認する
    • 現在のプロセス名は argv[0] から抽出する
    • プロセス環境変数をすべて解析し、内部文字列テーブル内の値と一致するかを確認する
    • 一致する環境変数があるか、プロセスが sshd でなければ悪性コードは実行を停止する
    • 内部テーブル中で唯一の変数 yolAbejyiejuvnup=Evjtgvsh5okmkAvj はこの文脈で キルスイッチ として動作する

  • trie ベースの文字列処理

    • バックドアの特徴の1つは、文字列操作に単一の trie 構造を使う点である
    • 関数名のような定数を直接比較したり文字列ハッシュで比較したりする代わりに、trie 参照結果が特定の定数値と一致するかを確認する
    • ELF ヘッダーのマジック値は trie で 0x300 を返す
    • system 関数名は 0x9F8 の返り値と一致する
    • trie は比較だけでなく、ホストバイナリ内の文字列検索にも使われる
    • 例として ssh-2.0 のような文字列ポインタを使う関数は、バックドア本体に不審なデータが残らないようホストバイナリ内で文字列を探す
    • 実装では 16 バイトのビットマスクを使う
    • 各半分は入力バイト範囲 0x00-0x3F、0x40-0x7F に対応する
    • trie のリーフノードは 2 バイトで、3 ビットはフラグとして使われ、残りは値または次ノード位置として予約される

シンボル解決と rtdl-audit フック

  • シンボル解決ルーチン

    • バックドアには ELF Symbol 構造を見つけるための シンボル解決ルーチン が少なくとも3つある
    • すべてのシンボル解決関数は、trie で検索するキーを入力として受け取る
    • ある解決関数はすべてのシンボルを走査し、目的のキーを持つシンボルを探し、見つかれば Elf64_Sym 構造を返す
    • この構造はその後、バックドア内部構造体を埋めて必要な関数ポインタを保持するために使われる
    • この過程は、Windows 脅威でよく見られる API ハッシュ化ルーチン に似ている
    • バックドアはその後、暗号ルーチンで使う OpenSSL libcrypto 関数を多数検索する
    • 見つけて解決した関数数を追跡し、この値で正常実行の可否と中断の要否を判断する

  • lzma_alloc を悪用した偽 allocator

    • 別のシンボル解決器は liblzma 自身の関数 lzma_alloc を悪用する
    • lzma_alloc は、デフォルト allocator である malloc またはカスタム allocator を使ってメモリを効率よく割り当てるのを助ける関数である
    • XZ バックドアでは 偽 allocator により、この関数が別のシンボル解決器のように動作する
    • 本来「割り当てサイズ」として使われる引数は、実際には trie 内のシンボルキーとして使われる
    • このトリックはバックドア解析を難しくするためのものだ
    • バックドアは実行中にシンボルを動的に解決し、すべてのシンボルを一度に解決する方法にも、必要時だけ解決する方法にも限定されない
    • 解決対象には通常の OpenSSL 関数から、マシン上でコマンドを実行する system のような関数まで含まれる

  • rtdl-audit ランタイムパッチ

    • バックドアは関数フックのため、動的リンカーの rtdl-audit 機能を使用する
    • 通常 rtdl-audit は、開発者がカスタム共有ライブラリを作成し、シンボル解決などのリンカーイベント通知を受け取るための機能である
    • XZ バックドアは別個の共有ライブラリを作る代わりに、メモリ内に既に登録されているデフォルトインターフェースを ランタイムパッチ してシンボル解決ルーチンを乗っ取る
    • 動的リンカーのメモリ領域にある dl_audit グローバル変数へ保存された悪性 audit_iface 構造体には、symbind64 コールバックアドレスが含まれている
    • 動的リンカーがこのコールバックを呼び出すと、すべてのシンボル情報がバックドア制御下に渡り、標的関数に対して悪性アドレスを返すことでフックが達成される
    • dl_audit と dl_naudit のアドレスは dl_main と dl_audit_symbind_alt 関数を逆アセンブルして取得する
    • バックドアには命令デコード用の内部最小 逆アセンブラ が含まれており、*audit アドレスのような特定値を見つける際に広く使われる

確認済みのバックドア配布物と検知情報

  • バックドア入りソース配布物

    • xz-5.6.0
      • MD5: c518d573a716b2b2bc2413e6c9b5dbde
      • SHA1: e7bbec6f99b6b06c46420d4b6e5b6daa86948d3b
      • SHA256: 0f5c81f14171b74fcc9777d302304d964e63ffc2d7b634ef023a7249d9b5d875
    • xz-5.6.1
      • MD5: 5aeddab53ee2cbd694f901a080f84bf1
      • SHA1: 675fd58f48dba5eceaf8bfc259d0ea1aab7ad0a7
      • SHA256: 2398f4a8e53345325f44bdd9f0cc7401bd9025d736c6d43b372f4dea77bf75b8

  • 分析された主要アーティファクト

    • bad-3-corrupt_lzma2.xz: 86fc2c94f8fa3938e3261d0b9eb4836be289f8ae
    • build-to-host.m4: b4dd2661a7c69e85f19216a6dbbb1664
    • good-large_compressed.lzma: 540c665dfcd4e5cfba5b72b4787fec4f
    • liblzma_la-crc64-fast.o: 212ffa0b24bb7d749532425a46764433

  • 既知のバックドア入りライブラリ

    • Debian Sid liblzma.so.5.6.0
      • MD5: 4f0cf1d2a2d44b75079b3ea5ed28fe54
      • SHA1: 72e8163734d586b6360b24167a3aff2a3c961efb
      • SHA256: 319feb5a9cddd81955d915b5632b4a5f8f9080281fb46e2f6d69d53f693c23ae
    • Debian Sid liblzma.so.5.6.1
      • MD5: 53d82bb511b71a5d4794cf2d8a2072c1
      • SHA1: 8a75968834fc11ba774d7bbdc566d272ff45476c
      • SHA256: 605861f833fc181c7cdcabd5577ddb8989bea332648a8f498b4eef89b8f85ad4

  • 検知名

    • Kaspersky 製品は攻撃関連の悪性オブジェクトを HEUR:Trojan.Script.XZ および Trojan.Shell.XZ として検知する
    • Kaspersky Endpoint Security for Linux は Critical Areas Scan タスクの一環として、SSHD プロセスメモリ内の悪性コードを MEM:Trojan.Linux.XZ として検知する
    • 提供された Yara ルールは、CVE-2024-3094 に関連する悪性 get_cpuid 関数を見つけるための liblzma_get_cpuid_function ルールである

関連記事

1件のコメント

 
GN⁺ 2024-04-13
Hacker News の意見

  • この文章は、実際に起きたことをむしろ控えめに言っているように思う
    バックドアの技術的側面よりも恐ろしいのは、ソーシャルエンジニアリングの量と水準だ。バックドアは最終成果物であり、それを入れられたのは、その時点で xz プロジェクト全体がすでに悪意ある行為者、つまり「Jia Tan」とその周辺に長期間掌握されていたからだ。メンテナに対して1年以上にわたって心理戦を仕掛け、メンテナ本人も他の誰も気づかなかった
    スパイ小説のような出来事で、こんなことが可能なら、今ほかのプロジェクトではいったい何が起きているのか気になってくる
    バックドアのコード自体にも同じ考え方が表れている。単に無害に見せかけようとするのではなく、コミットメッセージ、コメント、変数名、コマンドの選択などを通じて、表面上は何をしているのかという物語を積極的に作り出し、実際にはまったく別のことをさせていた。コードを先に調べた人が自分の理解を疑い、次にバグを疑い、かなり後になってようやく悪意を疑うような構造だ

    • 本当に信じがたいレベルだ。陰謀論のように聞こえるかもしれないが、原作者が時間を割けなくなり、最終的に悪い行為者へ所有権を渡すよう仕向ける現実世界の心理作戦があったのではないかとも思ってしまう
      どの情報機関であれ、この事件をさらに深く調査していることを願う
    • この件を教訓にしてほしい。実際には多くのことが起きている。世界中の政府支援機関や闇市場組織の中には、バックドアの確保を任務とするところが多く、資金も十分にある。それが彼らの仕事だ
      バックドア関連の HN スレッドごとに、こうした可能性をパラノイアやアルミホイル帽子扱いして否定するのを見ると苛立つ。起きていないことのように扱われているが、今回は捕まった具体例にすぎず、まだ捕まっていないものは数え切れないほどある
      今回はオープンソースプロジェクトだったので、発見はまだ比較的容易なほうだったにもかかわらず、幸運だった。ではクローズドソース製品を考えると、バックドアを入れることは、1つの組織に侵入するか圧力をかける問題にまで単純化される。こうしたことは頻繁に起きている。誰も信じたがらないが、よくあることだ。技術インフラ企業で働いたことがある人なら、いくつか話があるはずだ。NDA や、もっと深刻な理由で話しにくいが、実際に起きている
    • コードを調べる人に自分の理解を疑わせるという点には完全に同意する。この件に注ぎ込まれた操作、緻密さ、忍耐、執拗さは驚くべきものだ
      誰かの執着が生んだ結果かもしれないし、こうしたことを複数のプロジェクトに対して9時から5時までの仕事のように行う民間セキュリティ企業や国家主体の作業かもしれない

  • これまで関心が、バックドアがどう動作し、どう目的を達成したかに集中してきたのは当然だ
    それでも、ミスや過剰設計された部分についてのより深い分析も見てみたい。Bryan Cantril のインタビュー [1] で Andrés は、これは配布方法まで正確に理解して作られたものではない既製のバックドア部品のようで、愚かな部分が多いと述べている。たとえば、彼に調査を始めさせるきっかけになったシンボルテーブル検索がそうだった
    同様に、なぜ RC4 で48バイトを切り出したのかも気になる [2]
    もっと時間があったり、より優れたチームだったりしたら、どうすればもっと上手く作れたのか、あるいはどこでより大きく失敗したのかについての話を聞いてみたい
    [1] https://youtu.be/jg5F9UupL6I?si=gvXsYFXgagkGOMd4
    [2] https://twitter.com/matthew_d_green/status/17744729080201014...

  • 正しく理解できているなら、有用な強化策は、各動的リンクライブラリが自分専用の GOT を持つようにし、動的リンクが終わったらそのテーブルを読み取り専用としてマークすることだと思う。つまり、動的境界を越えて相手側の ifunc 項目をパッチできないようにする方式だ
    こうすれば、どこかにリンクされるものの実行はされないコードのサプライチェーンセキュリティを改善できるかもしれない
    さらに進めるなら、ifunc を宣言的な方式で実装し、リンクする各ライブラリで任意コード実行を引き起こせないようにしたほうがよいかもしれない。後方互換性のため現時点での実装は難しいだろうが、長期的には段階的に導入できそうだ。たとえば、あるライブラリを「宣言的リンク ifunc」機能ビット付きでビルドした場合、動的リンカが、接続されたすべてのライブラリに同じ機能フラグがないと実行を失敗させる、といった形だ

    • 別の角度から見ると、問題はビルドシステムだ
      現在、ほとんどのライブラリのビルドは、チューリング完全な環境を要求する非常に複雑で難解なスクリプトを実行する形になっている。これは攻撃者に無限の攻撃面を与え、ビルド過程が乗っ取られれば機会が生まれる
      実行器を制限された状態機械にとどめる宣言的ビルドプロセスへ移行すれば助けになるだろう。すべてのソースの塊が再現可能でなければならないという要求も検討に値する
    • 正しくもあり、そうでなくもあるが、概ね違う。こうした方式は ifunc をこのように単純に使うことは防ぐだろうが、重要なのは、このバックドアの作者が機密性の高いプロセスのアドレス空間に入るライブラリへ任意コードを注入できたという点だ
      その時点から、あらゆる防御は無力になる。望めば GOT を再び書き込み可能に再マップできるし、そうした行動が「不審」として検知されたり、OS が切り替えを阻止できたりしても、注入されたコードは何百もの別の方法で制御フローをひっくり返せる。任意読み書き、コード実行、すべてが可能だ。この段階の侵害を防ぐセキュリティ緩和策はない。望めば秘密鍵を流出させて攻撃者に直接送ることもできるし、シェルを起動することもできる。この段階で保護設計をしようとするのは無駄だ
    • 動的リンク完了後にテーブルを読み取り専用としてマークするのは、残念ながら機能しない。動的リンクは遅延方式なので、「完了」する瞬間がない
      正しい関数ポインタは最初に呼び出されたときにロードされ、スタブの代わりにテーブルへ挿入されるが、その時点は任意に遠い未来になり得る。実際、gtk アプリのような大規模なライブラリエコシステムでは、リンクされた関数の大半がそもそも呼び出されない
    • ホストアーキテクチャ向けにビルドするなら、損失なしに ifunc を完全にオフにできる。Gentoo では -march=native でビルドすることが一般的で、glibc の USE フラグで -multiarch を設定すれば ifunc の無効化は簡単だ。悪影響は見ていない
    • ライブラリのインポートをサンドボックス化できるプログラミング言語はあるのか？

  • 最初の3段階については、この記事はこの2週間で知られている内容に比べて、それほど多くを付け加えているわけではありません。フローチャート付きのよくまとまった記事、という程度です。
    ただ、バイナリをそこまで詳細に分析している部分は新しいように見えます。
    そこに出てくるソースコードはどうやって作ったのでしょうか？逆アセンブラをかけて、コードが何をしているかを理解したうえで、すべての名前を説明的な名前に置き換えたのでしょうか？2週間でやったこととしては相当な成果に見えます。

    • 著者は GReAT です。
      Global Research & Analysis Team, Kaspersky Lab
      https://securelist.com/author/great/
      記事の執筆者は Kaspersky Lab のマルウェア解析チームのようなので、バイナリのリバースエンジニアリングにはかなり長けている可能性が高いです。
    • 白いスクリーンショットで使われているツールは、デコンパイラである IDA Pro です。
      https://hex-rays.com/ida-pro/

  • 本当に気になるのは、xz の調査のきっかけになった SSH の初期遅延が正確には何によって起きたのか、という点です。誰か突き止めたのでしょうか？

    • 接続ごとに追加の ECC 演算を行いますが、最近の CPU で 500ms かかるような処理ではありません。
      コードをリバースエンジニアリングした人たちによると、コマンドメッセージを SSH ホスト鍵にも結び付ける必要があるそうです。そのため、ホスト鍵が RSA 鍵なら、接続ごとに追加の RSA 復号演算も実行していた可能性があります。
      それなら遅延の原因としては十分あり得そうです。
    • わざとそうした可能性もあります。
      先にコード注入を試みなくても、外部からサーバーが感染しているかどうかを見分ける簡単な方法です。

  • 作成者たちは glibc の内部構造を非常に深く理解しています。ソースコードに首まで浸かっていなければ分からない種類の内容で、新しい手法も多くあります。
    カスタム ELF パーサーとディスアセンブラがあまりに複雑なので、そのコードが過去に別の場所で使われたことがない、あるいは今後も再利用されない、と想像するのは難しいです。
    この事件が相応の真剣な調査を受けるのか気になりますが、そうはならなさそうです。

  • 結局、この件を表面化させた Valgrind エラーと SSH の遅延を引き起こしたバックドアのバグを分析した人はいるのでしょうか？

    • 明らかに不正なメモリ書き込みだったようです: https://www.mail-archive.com/valgrind-users@lists.sourceforg...
      Valgrind の「修正」は ifunc を無効化することで、その結果バックドアも無効化され、エラーが消えました。
      遅延は、私の理解ではバックドアが行ったすべてのシンボルと命令の探索に起因しています。

  • 逆説的に見ると、攻撃者がスクリプトやコードで検出を避けるために費やした労力を考えると、このプロジェクト全体が注意をそらすためのものだったり、複数の試みが同時に進んでいる間の予備策だったりする可能性もあります。
    こうしたものの一歩先を行くにはどうすればよいのでしょうか？コミュニティが SSHD に集中することは、システム全体の他の部分に影響するのでしょうか？他の技術的側面や社会的側面には？
    アルミホイル帽は面白いですね。

    • 楽観はしていません。Flathub の flatpak バイナリの内容を実際に監査している人もほとんどいません。本当にソースからビルドされたのでしょうか？作成者がそうだと証明する、という形です。このバックドアのような精巧な配送メカニズムすら必要ないかもしれません。
    • すべてを自分たちで書き、検証済みの開発者からなる専任チームを置くことはできます。
      あるいは Microsoft のようなところのクローズドソースを買って、彼らにコードをより厳格にレビューするリソースと意思があることを願う方法もあります。
      そして、不審なネットワーク活動や権限昇格の試みを検出する優れたセキュリティ運用チームを置く、というアプローチも常にあります。
    • 似たようなバックドアの一歩先を行く方法としては、sshd トラフィックを spiped トンネルで包むことを考えています。Spiped はソースからコンパイルして静的リンクし、最後の安定版は 2021 年のものです。
    • オープンソースのコントリビューターを疑おう、というのが私のアルミホイル帽的なアイデアです。特定の国の出身だからでも、実際に会ったことがなさそうだからでもありません。
      ただ、作業中のプロジェクト以外に履歴も足跡もないコントリビューターは、今後は危険信号と見るべきです。
    • アルミホイル帽は不要です。FOSS プロジェクトには有名になる前からバックドアが仕込まれてきましたし、今回の違いは国家支援のアクターがやっているという点です。
      以前のグループである GOBBLES、ADM、ac1db1tch3z、~el8 もこうしたことをしていましたし、isec.pl のような民間の「セキュリティ研究者」もやっていました。
      今回問題なのは、国家アクターが、基盤プロジェクトを低賃金で支える時代を作った企業資本主義を悪用しているからです。悪意あるアクターには、目標達成のためのリソースが事実上無制限にあります。
      それが結局、NSO や Zerodium のような組織への需要と誕生を生んだと言えます。
      それ以前は、エクスプロイトやバックドアの価値はほとんどなく、ハッカーたちは Qualys のような企業からの支援や採用を期待していました。

  • Google のゼロデイ脆弱性ハッキング分析を何度か見ましたが、それらも非現実的なほどすごいものでした。それでも今回のハッキングは、歴代でも屈指のものになりそうです。

  • xz リポジトリが GitHub に再び上がっているのを見ました。Lasse と新しいコントリビューターが整理していました。ifunc サポートを削除し、blob なしでテストファイルを作れるようにするテストファイル生成コードをリポジトリにコミットしていました。良い方向に進んでいるように見えます。