何が起きたのか—Guix に複数の重大脆弱性
GNU Guix プロジェクトは、パッケージ管理・構成管理ツールの guix substitute と guix pull コマンドに、複数の重大な脆弱性（CVE ID はまだ割り当て待ち）を確認したと発表しています。（出典）
最も危険なのは guix substitute の脆弱性で、これによるリモート攻撃は以下のいずれかが可能です。
- リモートからの権限昇格（guix-daemon ユーザーへの昇格）
- ストアデータの遠隔破壊
- build daemon ユーザーがアクセス可能な機密ファイルの漏洩
デーモンが root で動作している場合、攻撃者は /etc/passwd などのシステムファイルを直接改ざんできる可能性があります。
影響を受けるのはすべてのシステムです。guix-daemon が root で実行されているかどうかに関わらず、何らかの被害を受ける可能性があります。
脆弱性の技術的詳細—なぜこんなことが起きたのか
この脆弱性の本質は、ダウンロード検証の順序の問題にあります。
| 項目 | 現在の実装 | 望ましい実装 |
|---|---|---|
| 処理順序 | substitute をダウンロード中に展開 | 全体ダウンロード後にハッシュ検証して展開 |
| 検証タイミング | 部分的なデータから開始 | 完全なアーカイブの整合性確認後 |
| リスク | ファイル破壊が既に発生 | 不正ファイルを事前に検出 |
具体的には、以下の 3 つの脆弱性が連鎖しています。
脆弱性 1: restore-file- の硬化不足
Guile コードが substitute 展開に使う restore-file- 手続きが、悪意あるデータへの防御を備えていません。ダウンロード完了前に即座に展開されるため、ハッシュ検証される前にファイル破壊が完了してしまいます。
脆弱性 2: narinfo の署名不備
Substitute のメタデータ（narinfo）を取得する fetch-narinfos は、X.509 証明書検証を行いません。これは PKI に依存しないという設計思想から来ていますが、結果として 署名済みのハッシュ値以外の部分（substitute の URL など）が改ざんされても検出できないという状況を招いています。
攻撃者が narinfo の URL 部分だけを攻撃者制御サーバーに置き換えれば、たとえダウンロード手続きが HTTPS で証明書検証を行っていても無意味になります。証明書は攻撃者の URL に対して有効であれば足りるからです。
脆弱性 3: 影響範囲の拡大
restore-file- は guix offload、guix archive --extract、guix challenge など複数のユーティリティでも使われています。信頼できないバイナリ入力を与えると、それらすべてが同じ方法で悪用される可能性があります。
開発環境でローカル LLM や Stable Diffusion を動かす際に、guix で環境を構築している方も多いと思います。そうした場合、ローカルネットワーク上での MITM 攻撃の対象になり得るわけです。
脆弱性 4: guix pull の任意ファイル作成
別の脆弱性として、guix pull と guix time-machine にも問題が見つかっています。channels ファイルの制御が可能な攻撃者は、ユーザーが作成権限を持つ任意の場所にファイルを作成・上書きできます。サンドボックスの有無や introduction チェーンの信頼性に関わらず、です。
こちらは主に DoS（サービス妨害）リスクですが、理論上はより深刻な影響も考えられると指摘されています。
すぐに取るべき対策
Guix プロジェクトは以下の対応を強く推奨しています。
- 直ちに guix-daemon をアップデートしてください。
- アップデート時に、すべての guix コマンドに
--no-substitutesフラグの追加を慎重に検討してください。このフラグを使えば、バイナリ substitute をダウンロードせず、ソースから直接ビルドするようになります。
ただし --no-substitutes はビルド時間を大幅に増加させるため、本当に必要な場合のみの使用を勧めます。より実務的には、以下の 2 ステップ対応が現実的ではないでしょうか。
- まず緊急パッチが出たら即座にアップデート
- 信頼できない環境でのバイナリ実行を避ける（例えば本番環境のみ guix を使うなど）
ローカル開発環境と本番環境で guix の扱いを分けている方は、本番側を優先してパッチを当てるべきです。
今後の展開—セキュリティアップデートの公式情報を追跡しましょう
現在 CVE ID の割り当てを待っている状況です。正式な CVE が発行されれば、各 Linux ディストリビューションのセキュリティ勧告システムにも登録される見込みです。
Guix を使用している開発者の方は、公式ブログ（https://guix.gnu.org）と GitHub の security advisory を定期的に確認することをお勧めします。
同時期に他のオープンソース・ツールチェーンでも脆弱性が相次いで報告されている傾向があります。参考までに、KDE Plasma のサンドボックス回避の脆弱性やGoogle Cloud の不正アクセス事例なども報告されており、ツールとインフラの両面でセキュリティ意識を高める必要があると感じます。
こうした脆弱性の報告が増えている背景には、セキュリティ研究コミュニティの成熟と、open source 環境への関心の高まりが反映されているのではないでしょうか。開発者の皆さんは、使用しているツールのセキュリティ情報を主体的に追跡する習慣をつけることが、今後ますます重要になると予想されます。
