TL;DR
2024年3月、Linux の広範なシステムに組み込まれている圧縮ライブラリ xz utils に、CVSS 10.0 のバックドア(CVE-2024-3094)が発見された。攻撃者「Jia Tan」は約2年かけて正規の OSS コントリビューターとして信頼を積み、実質的なメンテナー権限を獲得した後、リリースビルドスクリプトに巧妙なバックドアを埋め込み、コード署名済みの正規リリース(5.6.0 / 5.6.1)として配布した。暗号署名は有効だった。「Jia Tan」が正規の開発者であるという前提が、最初から偽りだったのである。コード署名は「誰の鍵が使われたか」を証明するが、「その鍵保有者のアイデンティティが真正か」は証明しない。この落差が、国家レベルと疑われるアクターによる OpenSSH デーモン経由の大規模 RCE 経路を、安定版リリース手前まで到達させた。
事案概要
- 対象: xz utils(liblzma)— Linux / Unix 系システムで広く使われる圧縮ライブラリ。多数のディストリビューションに標準搭載
- CVE: CVE-2024-3094(CVSS スコア: 10.0)
- 発見者: Andres Freund(Microsoft 所属エンジニア)。SSH ログインのわずかな遅延に気づき、2024-03-29 にメーリングリストへ報告
- 攻撃者: “Jia Tan”(GitHub: JiaT75)— 実在が確認できない人物。状況証拠から国家レベルのアクターが関与したとされる
- バックドア内訳: 悪意あるコードはソースツリー直接ではなく、Autoconf ビルドスクリプト(
build-to-host.m4)と、.tar.gzリリースアーカイブにのみ含まれる難読化されたテストファイル群の組み合わせとして隠蔽された。git cloneでは現れない - 影響範囲: liblzma にリンクした systemd-based の
openssh-serverを通じて、認証済み公開鍵の保有者が RCE を実行できる経路が開く。Fedora Rawhide、一部の Debian testing / unstable に到達。主要安定版には到達前に発覚 - 根本原因: 技術的な脆弱性ではなく、信頼の来歴の偽装。「Jia Tan」は約2年のコントリビューション履歴と、プロジェクトの既存メンテナーへの社会工学的接近を通じて、リリース権限を含むメンテナー権限を獲得した
- コード署名との関係: リリースアーカイブは「Jia Tan」の PGP 鍵で署名されており、技術的には署名は有効。しかし「Jia Tan」というアイデンティティが真正であることを独立検証する仕組みはどこにも存在しなかった
- 核心: コード署名は「この鍵が使われた」ことを証明するが、「その鍵保有者のアイデンティティが、プロジェクトが信頼した実在の人物と同一か」は証明しない。「Jia Tan」は約2年かけて信頼させた架空のアイデンティティであり、鍵の来歴は正しくともアイデンティティの来歴は最初から偽りだった。
タイムライン
- 2021年末〜2022年初頭: “Jia Tan” が xz プロジェクトへのコントリビューションを開始。品質の高いパッチを継続的に投稿し信頼を獲得
- 2022〜2023年: コミット権を取得し、既存メンテナー(Lasse Collin 氏)の作業を徐々に引き継ぐ形でコアコントリビューターとしての地位を確立。同期間に外部から既存メンテナーへ「もっと積極的にリリースを」とプレッシャーをかける不審なアカウント群も確認されている
- 2024-02-24: xz utils 5.6.0 リリース。バックドアを含むビルドスクリプトが初めて含まれる
- 2024-03-09: xz utils 5.6.1 リリース。バックドアの細部が更新される
- 2024-03-29: Andres Freund が Valgrind 出力と SSH ログインのわずかな遅延(約 500ms)の異常に気づき、調査の結果 liblzma のバックドアを発見。Openwall メーリングリストおよびセキュリティ関係者に報告
- 2024-03-29〜30: CISA・各 Linux ディストリビューターが緊急勧告を発行。影響を受けたバージョンのダウングレードを推奨
- 2024-03-29以降: “Jia Tan” のアカウント活動が停止。詳細な技術解析が Binarly・Openwall 等から相次いで公表
注: 固有名・CVE・バージョンは Openwall(Andres Freund の一次報告)・NIST NVD・CISA の各一次情報に基づき、国家レベルのアクターへの帰属は状況証拠に留まり確定されていない。各ディストリビューターの対応状況は時点により異なるため最新情報を参照のこと。
攻撃ベクター
- アイデンティティの長期構築: “Jia Tan” が偽のアイデンティティで OSS プロジェクトにコントリビューションを開始。本物と区別がつかない高品質なパッチを継続投稿し、コミュニティの信頼を蓄積する
- メンテナー権限の取得: 既存メンテナーへの直接接触と継続的な貢献により、リリース作成・署名を含む実質的なメンテナー権限を獲得
- バックドアの隠蔽: バックドアをソースコードに直接書かず、Autoconf ビルドスクリプトとリリースアーカイブ内のテストファイルの組み合わせとして実装。
git cloneからのソース確認では検出できない - 正規リリースとしての署名・配布: “Jia Tan” の PGP 鍵で署名されたリリースアーカイブ(5.6.0 / 5.6.1)として配布。各ディストリビューションが正規パッケージとして取り込む
- liblzma 経由の RCE 経路: systemd-linked の
openssh-serverが liblzma を読み込む際にバックドアが活性化。公開鍵認証の処理を hook し、攻撃者の特定の秘密鍵の保有者が RCE を実行できる状態になる - (発覚により未完): 安定版ディストリビューションに到達する前に発見され、攻撃が実際に使用された証拠は確認されていない
構造的論点
本事案は Pillar 01(来歴証明)の code-provenance カテゴリに属する。中心的な**失敗 primitive は「コード署名が『この鍵保有者が署名した』ことを証明するが、『この鍵保有者のアイデンティティが、プロジェクトが信頼した人物と同一か』を証明しない」**である。来歴証明の根本論点の露呈にほかならない。
OSS のコード署名は通常、「この鍵を持つ人物が署名した」という技術的事実を確認する。しかし「この鍵を持つ人物が、コントリビューションを承認した組織・コミュニティが意図した人物か」は別命題である。“Jia Tan” は実在しない(あるいは偽の)アイデンティティで鍵ペアを生成し、そのアイデンティティを2年かけてコミュニティに信頼させた。「鍵の来歴は正しい」が「鍵保有者のアイデンティティの来歴は偽りだった」。
Brief No.004(Megalodon GitHub サプライチェーン)との比較:Megalodon は既存の正規開発者の認証情報(PAT等)を奪取して push した(identity の窃取)。本事案は最初からアイデンティティ自体が架空だった(identity の偽造)。どちらも「commit / release の author が正規の開発者か」を独立検証する層がない点では同型だが、本事案は攻撃の準備期間(2年)と隠蔽技術の精度において、国家レベルの関与を示す最も精緻な事例の一つである。
Brief No.014(TanStack npm 汚染)が「正規 OIDC 署名が有効でも成果物は悪性」を示したとすれば、本事案は「正規 PGP 署名が有効でもアイデンティティは偽造可能」を示す対になる事例である。
検出と証明の落差
本事案で検出は効いた。Andres Freund の異常検知(SSH 遅延・Valgrind 出力の差異)という、極めて偶発的かつ深い技術的観察が唯一の発見経路だった。CISA と各ディストリビューターの迅速な対応で安定版への到達を防いだのである。もし Andres Freund がこの異常に気づかなければ、メジャー Linux ディストリビューションの安定版に含まれた可能性があり、検出層が本事案の被害拡大を食い止めた役割は否定されない。
だが、証明は無かった。コード署名は有効だったため、署名検証ツールはバックドアを検出しない。バックドアはソースツリーに直接存在せず、リリースアーカイブのビルドプロセスに埋め込まれていたため、ソースコードレビューのみでは検出困難だったのである。根本問題は「“Jia Tan” のアイデンティティが真正な開発者のものか」を、コントリビューション開始時点あるいはメンテナー権限付与時点で独立検証する仕組みが存在しなかったことにある。検出は事後に異常の輪郭を捉えたが、「誰を信頼するか」という accept の判断そのものを変えるものではない。
Lemma で変わるのは、コードを誰が書いたかだけでなく、「その誰かのアイデンティティが、プロジェクト・組織が承認した実在の人物と対応するか」を独立検証可能な暗号証明として固定する点である。鍵ペアの生成と、鍵保有者のアイデンティティ来歴を分離させない設計、及びメンテナー権限付与時の属性証明を提供する。事後の検知が証明にならない論点は「AI 時代のサイバー防衛に残された、最後の層」(Lemma、2026-05)、行動前に独立検証する設計は「Proof-as-Auth: 鍵を一度も送らずにサインインする」(Lemma、2026-05)を参照。検出と事前証明は代替ではなく 補完 の関係にある。
対応経緯と業界動向
- Andres Freund(Microsoft): 個人の深い技術的観察により発見・報告。コミュニティと CISA に即日通知
- CISA: 緊急アラート発行(2024-03-29)。影響バージョンからのダウングレードを推奨
- 各 Linux ディストリビューター: Fedora・Debian・openSUSE・Arch 等が緊急対応でダウングレードパッケージを配布
- Binarly: 難読化されたビルドスクリプトとテストファイルの詳細な技術解析を公表
- 国際的帰属議論: タイムゾーン・コミット時刻・言語的特徴の分析から、国家レベルのアクターの関与が広く議論されている(確定帰属なし)
- 業界への論点: OSS エコシステムにおいて「長期的な信頼の積み上げ」によるサプライチェーン攻撃の実行可能性が実証された。コントリビューター・メンテナーのアイデンティティ検証の必要性が改めて提起され、Sigstore 等の code signing 標準の普及議論が加速した
Lemma による分析
本事案で露呈した検出と証明の落差(コード署名は鍵保有者を証明するが、鍵保有者のアイデンティティの来歴は証明しない)に対して、Lemma は以下を提示する。
- 開発者アイデンティティの来歴証明: コントリビューター・メンテナー権限付与の時点で、アイデンティティが「実在する組織・人物と紐づいているか」を ZK 証明として固定する。鍵生成とアイデンティティ来歴を切り離さない
- 権限付与の事前証明: メンテナー権限付与・リリース権限委譲の各ステップで、委譲者と受領者の双方の来歴を証明可能な記録として残す
- ビルド成果物の来歴連鎖: ソースコードの author 来歴 → ビルドプロセスの実行者来歴 → リリースアーカイブの署名者来歴 を切れ目なく連鎖させ、任意の段での偽装を検出可能にする
- リリースアーカイブとソースの一致証明:
git cloneで確認できるソースとリリースアーカイブの差分を、ビルド実行前に独立検証可能な形で開示する
これは「暗号論理的に有効 ≠ アイデンティティの来歴が正しい」という来歴証明カテゴリの設計思想であり、Andres Freund のような事後の検出を置き換えるものではなく、accept 前にアイデンティティの来歴を固定することで両者を 補完 させる。設計の詳細はPillar 01 — 来歴証明、適用範囲はTrust402を参照。
Sources
- Andres Freund(一次報告): Openwall メーリングリスト投稿「backdoor in upstream xz/liblzma leading to ssh server compromise」(2024-03-29)— https://www.openwall.com/lists/oss-security/2024/03/29/4
- CISA 緊急アラート: “CISA Adds One Known Exploited Vulnerability to Catalog” / XZ Utils Backdoor Advisory(2024-03-29)
- Binarly: “XZ Utils Supply Chain Backdoor: Technical Analysis”(2024-03〜04)
- NIST NVD: CVE-2024-3094 エントリー — https://nvd.nist.gov/vuln/detail/CVE-2024-3094
- Ars Technica: “What we know about the xz Utils backdoor that almost infected the world”(2024-03-29)
Brief 配布について
本資料は公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません。
(c) 2026 FRAME00, INC. — Built for decisions that matter.