ハクソク

世界を動かす技術を、日本語で。

QubesOSにおけるコピー先VMのエラーレポートバックチャネルを介した任意コード実行

2026年8月30日原文(qubes-os.org)

概要

Qubes OS のセキュリティ速報（QSB）118号が公開されました。 qvm-copy-to-vm のエラー報告処理における dom0任意コード実行脆弱性 が対象です。 影響を受ける全ユーザーは、 通常のアップデート を継続するだけで対応可能です。 技術的な詳細やパッチ情報、 PGP署名の検証方法 も案内されています。 本記事では、QSB118号の内容要約と、 対応手順・署名検証方法 を解説します。

Qubes Security Bulletin 118 概要

  • 公開日：2026年8月28日、Qubes Security Teamによる発表
  • 脆弱性内容
    • dom0から悪意あるqubeへ qvm-copy-to-vm を用いてファイルコピー時、攻撃者が 任意コマンドをdom0で実行可能
    • 攻撃者がqubeを事前に侵害している場合、 Qubes OS全体の制御権奪取 につながるリスク
  • 影響範囲
    • 全てのQubes OSリリース が影響対象
  • ユーザー対応
    • 通常の アップデート手順 を継続するのみでOK
    • 特別な操作は不要

技術的詳細

  • 脆弱性の発生箇所
    • dom0の qvm-copy-to-vm ツールによるファイル転送時のエラーメッセージ処理
    • エラー発生時、qube側からdom0に返すファイル名が 不十分なサニタイズ のみでGUIエラー表示コマンドに渡される
    • エラー表示コマンドが system() 経由でシェル実行されるため、 シェルメタキャラクタ が残存しコマンドインジェクションが成立
  • 対象外
    • VM側のqvm-copy-to-vmは system() を使用せず、影響なし

パッチ情報

  • パッチ提供パッケージ
    • Qubes 4.3のdom0用： qubes-core-dom0-linux, version 4.3.22
  • 適用方法
    • コミュニティによる短期間のテスト後、 安定版リポジトリ に移行
    • Qubes Updateツールまたはコマンドラインからインストール
  • 詳細手順

脆弱性発見者・参考情報

QSB・PGP署名の意義と検証方法

  • QSBとは
    • Qubes Security Teamが発行する セキュリティ速報
    • 新規脆弱性の概要、影響、パッチ情報、必要なユーザーアクションを記載
  • PGP署名の重要性
    • QSBの 真正性保証 のため、全てのQSBに OpenPGP署名 を付与
    • 偽造QSBによる誤った操作・マルウェア導入のリスク防止
  • 署名検証手順（Linux例）
    • Qubes Master Signing Key (QMSK) を取得
      • $ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
    • インポートした鍵の フィンガープリント表示
      • $ gpg --edit-key 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
      • gpg> fprで確認
    • フィンガープリントの多元照合 による鍵の真正性検証
    • 鍵が本物と確信できたら、 trustレベルを5（ultimate） に設定
      • gpg> trust → 5を選択

まとめ・推奨アクション

  • 全Qubes OSユーザーは通常のアップデートを継続
  • QSBやパッチ情報の真正性はPGP署名で必ず検証
  • 疑問点は公式ドキュメントやQubes Security Teamへ問い合わせ

Hackerたちの意見

Qubesにはまだまだ感心してるし、オレがそんなに狙われてるわけじゃないから、あのレベルのオプセックが必要だとは思わないんだよね（オレのノートパソコン全部に対して）。いつかAIを使ったキルチェーンが広まって、Qubesがローカルで使う数少ないユーザーにとっての最低限のレベルになるかもしれないね。dom0から他のqubeに何かをコピーすることは絶対にしないよ、影響は少ないから。

└

「dom0から他のキューブに何かをコピーすることはなかったな。影響は少ないし。普通はログをコピーして、問題チケットを開くくらいだよ。」

QubesOSにはまだ感心してるし、専用の「ファイナンス」用ノートパソコンで使ってるよ。個人的には、QubesOSが進まない理由はグラフィックスのハードウェアアクセラレーションがないからだと思う。今、デュアルモニターのセットアップが人気になってきてるから、これがセキュリティの考慮点の回避策になるかもね。

└

その理由で一度QubesOSをやめたことがあるけど、今は別のコンピュータでまた使ってるよ。欠点はあっても、TorやVPN、普通のインターネットで異なるアプリを同時に動かせるのは本当にいいよね。安全じゃないバイナリを隔離できるし、VMのバックアップも簡単だし。KVMをベースにした似たようなディストロが作られたら、標準のカーネルが使えるからすごくいいと思う。

└

問題は、誰もやりたくないわけじゃなくて、GPUスタックがまさにQubesがDom0から遠ざけるために存在する巨大なドライバー面だからなんだよね。第二のモニターがあっても、結局誰かがそのドライバーを信頼しなきゃいけない。

└

これはvirtioネイティブコンテキストで解決された問題みたいだね。仮想マシン内でmesaドライバーを実行して、そのioctl呼び出しをホストカーネルのGPUドライバーにプロキシするだけだよ。今のところ、mesaの主要なGPUドライバーはこの機能をサポートしていると思う。なんでQubesOSがまだこれを採用してないのか不思議だな。

これは深刻だね。QubesOSの攻撃面がこんなに小さい（安全に設計されてる）のに、まだ脆弱性が見つかるって考えさせられる。私の理解では、この脆弱性はDom0からVMにコピーする時にだけ発生するみたいだね。>「qvm-copy-to-vmのVMバリアントは影響を受けないことに注意してください。エラーレポート機能のバージョンがsystem()を使っていないからです。」Dom0は通常の作業に使うべきじゃないし、感染の可能性があるVMとやり取りするのは絶対に避けるべきだから、この攻撃の範囲は思ったよりも狭いよ。一方で、うまくいくと、特権が直接Dom0に昇格するんだよね。

└

あなたの言う通り、dom0にコピーするのはベストプラクティスじゃないし、昔から警告されてるけど、ユーザーグループが技術的に考えないことが多かった（ジャーナリストや反体制派など）ことを考えると、ユーザーがやってはいけないことをしても、qubesの隔離が保たれるようにするのは哲学の一部だったんだよね。ユーザーを信じるな、ユーザーランドを信じるな、ソフトウェアを信じるな、みたいな感じで。

└

セキュリティを考慮して設計されている まあ、これがデザインが安全じゃないって言ってるわけじゃないけど、system()は現代のコードにはそぐわない呼び出しの一つだよ。設計上、不安定なんだ。> commandの一部として使われるユーザー入力は、予期しないシェルコマンドやコマンドオプションが実行されないように、慎重にサニタイズする必要がある。特に特権プログラムからsystem()を使うときは、そのリスクが非常に重大になる。（—man 3 system）

またTheo DeRaadtを思い出させるね: https://marc.info/?l=openbsd-misc&m=119318909016582

└

Theoはすごく洞察力のある人だけど、意見も強いよね。真実はその間にあると思う。特に、仮想化機能がどんどんハードウェアに移行している今、それを第二のセキュリティバリアとして使わないのは愚かだと思う。

└

ピークTheo！この爽快な真実の告白は2026年には根絶されてしまった。

Hacker Newsで議論の続きを見る