KDE Plasmaでサンドボックスを破る任意コード実行の脆弱性

 (blog.kimiblock.top)
1 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • KDE Plasmaのウィンドウ管理動作により、サンドボックス化されたアプリがユーザーのクリックをきっかけにホスト上の任意のバイナリを実行できることがPoCで確認された
  • 主な原因は、KWinがアプリの提供するapp_idを信頼し、実際の.desktopファイルとの照合なしに/proc/PID/cmdlineベースの実行パスを残していた点にある
  • PoCはArch Linuxホスト、Flatpakアプリ、改変したMesa eglgears_waylandを組み合わせ、/usr/bin/kcalcがサンドボックス外で実行される流れを再現している
  • ユーザーがタスクバーアイコンのOpen New Windowを選択するか中クリックすると、対象プロセスがapp.slice cgroupとホストのマウント名前空間で公開された状態で起動する
  • 緩和するには、サンドボックスのsecurity context、XdpAppInfo、control groupsでアプリIDを確認し、.desktopファイルと一致しないウィンドウでは新規ウィンドウの起動を防ぐ必要がある

PoCが示したサンドボックス脱出の流れ

  • 悪意あるサンドボックスアプリは、ユーザーがOpen New Windowを呼び出した瞬間に別のアプリになりすまし、ホスト上で任意のバイナリを実行できる
  • PoCはFlatpakで再現されたが、セキュリティコンテキスト対応の有無にかかわらず、他のサンドボックスにも適用され得ると整理している
  • 実験構成は次のとおり
    • Arch Linuxホスト
    • ビルド依存関係wget、unzip、meson
    • 権限を付与していないFlatpakアプリio.github.johannesboehler2.BmiCalculator
    • サンドボックス内ではビルドが容易でないため、悪意あるバイナリのパスだけをFlatpakに渡す
    • 指定対象バイナリ/usr/bin/kcalc
  • 悪意あるバイナリを実行すると、タスクバーにはKCalcアイコンが表示される
  • ユーザーが右クリックしてOpen New Windowを選択すると、/usr/bin/kcalcがサンドボックス外で起動する
    • 実行場所はapp.slice cgroup
    • マウント名前空間はホスト側
    • 結果として完全に露出した状態で実行される

発見過程と手がかり

  • KDE PlasmaでPortableサンドボックスをQEMU仮想マシンとしてテストしていたところ、一部のウィンドウが適切な.desktopファイルに関連付けられず、タスクバーに一般的なWaylandアイコンとして表示された
  • この現象はKWin trusts on Apps fully for app_idとして報告され、アプリが他のアプリになりすませる問題につながる
  • その後、タスクバーで誤って中クリックしたところ、デフォルト動作としてOpen New Windowが呼び出された
  • 新しいウィンドウは起動したものの、保存済みのログイン資格情報や変更済みの設定を使用しておらず、KWin Debug ConsoleのPIDとprocfsのcontrol groupsおよびrootfs情報を合わせて確認することで、サンドボックス脱出が明らかになった

脆弱性の仕組み

  • KWinがウィンドウを実際の.desktopファイルに関連付けられなくても、実行するargv0を探す経路が残っている
  • 実験の結果、/proc/PID/cmdline経由で値を読み取っているという推測が正しかった
  • 問題は、既存のアプリケーションインスタンスをサンドボックス外で実行する程度にとどまらない
  • 権限のないプロセスを含むすべてのプロセスは、argv0を変更できる
    • マウント名前空間も選択肢になり得るが、柔軟性は低いと整理している
  • アプリが提供するapp_idに対する保護の欠如と、/proc/PID/cmdline読み取りの危険性が組み合わさり、ホスト上で任意コード実行が可能になる

デモと実際の攻撃シナリオ

  • デモコードはGalaxySnailが作成し、Mesaのeglgears-waylandを使用している
  • デモの流れは次のとおり
    • mesa-demos-argv0リポジトリをクローン
    • src/egl/opengl/eglgears.cのmain関数内の指定コマンドを任意のコマンドに変更
    • meson setup build && meson compile -C buildでビルド
    • ./build/src/egl/opengl/eglgears_waylandを実行
    • タスクバーアイコンを中クリック、またはコンテキストメニューからOpen New Windowを選択
    • 指定した悪意あるバイナリが起動する
  • 実際の攻撃では、$HOME配下にシェルスクリプトを作成する方法が可能
    • $HOMEは一般にホスト上でも同じパスにある
    • 悪意あるアプリはargv0を密かに作成するか、ダウンロードしたバイナリに置き換えられる
    • ユーザーがOpen New Windowをクリックするか、誤ってアプリアイコンを中クリックすると、セッションを完全に制御できる

提案された修正方針

  • KDE Plasmaがこのエクスプロイトを防ぐには、アプリが提供したIDをそのまま信頼してはならない
  • アプリIDは次の経路から取得すべきだと提案している
    • サンドボックスのsecurity context
    • XdpAppInfo
    • control groups
  • 特定のウィンドウが.desktopファイルと一致しない場合、Open New Windowを許可すべきではない
  • KDE Securityのメールから更新は受け取っていない状態である

公開タイムライン

  • 元のメールではarbitrary code executionをRCEと誤って表記した
  • すべてのイベントはUTC+8、24時間表記基準
  • 2026年4月1日 23:51、最初のメールをsecurity@kde.orgに送信
  • 2026年4月2日 00:15、David Edmundsonが報告を確認する返信を送信
  • 2026年4月2日 00:24、David Edmundsonは当該機能が.desktopファイルのExec=を使用しており、任意コード実行には使えないと考えていると返信
  • 2026年4月2日 11:59、GalaxySnailの協力により、.desktopファイルに依存しない別のPoCが動作することを確認
  • 2026年4月2日 18:26、エクスプロイトファイルと説明を含む追加メールをsecurity@kde.orgに送ったが、返信は受け取っていない
  • 2026年5月2日 11:59、Plasma 6.7 Betaでエクスプロイトがパッチされていないことを確認
  • 2026年7月2日 18:30、エクスプロイトが有効な状態で90日の待機期間を超えたため公開を進めた
  • パッチされておらず追加返信もなく、一般的な90日の待機期間が過ぎた後、認知向上のため公開を決定した
  • KDE開発者を批判しようとするものではなく、OSSプロジェクトは最近スパムに悩まされており、人間にも処理能力の限界があるが、プロセスは改善できると付け加えている

関連記事

1件のコメント

 
GN⁺ 5 시간 전
Lobste.rs の意見
  • Linux 向けの Capsicum の試みが NIH のせいで潰れなければ本当によかったのにと思う
    デスクトップアプリのサンドボックス化には、今の Linux で同じことをやろうとして積み上げられている雑多な方式よりも、はるかに優れたモデルだ。ランチャーがメタデータに基づいて初期権限セット、つまりファイルディスクリプタを渡し、アプリはそれ以外にはアクセスできず、powerbox が別のファイルの開く・保存の権限を提供する構造になっている
    • Linux のコンテナモデル全体が、どこか雑な概念の継ぎはぎのように見える
      Kubernetes のサービスのように、何らかの神のようなプロセスがサービスをオーケストレーションする環境には概ね合っているが、デスクトップではあまり適していない。ユーザー空間でより低い権限の cgroup/namespace に入りたいのに、root デーモンや setuid のような儀式を経なければならず、結局は権限昇格のリスクを招いている
    • 理論上は、Flatpak のような主要な Linux デスクトップ向けサンドボックスツールは SCM_RIGHTS + Wayland + D-Bus を基本要素としてこのように動くべきだ
      目を細めて見れば、安全なデスクトップの輪郭は見えてくる
      しかし実際の実装は全体的に寛大すぎるか、柔軟性がないか、半分壊れている。サーバーワークロードの保護ほど、エンドツーエンドのデスクトップセキュリティを気にしている人がいないように見える。だから gVisor や Firecracker はうまく動くのに、Flatpak は基本的な Gtk+ アプリ一つですらフォントを壊さずに動かすのが難しく、すべての Wayland コンポジタが信頼できるデスクトップ基盤の半分を再実装しなければならない
      Android が信頼できないコードを実行できるほど十分に強化された Linux ディストリビューションとしてかなりうまく機能しており、iOS と macOS はユーザー向けアプリのサンドボックス化も十分実用的になりうることを示しているのを考えると、なおさら気まずい。彼らがやっている通りにすればいいだけだ。いったいなぜウィンドウマネージャ内の何かが /proc/{pid}/cmdline を読んでいるのか
  • アップストリームがパッチできなかったあとで 全面公開 に至った状況なので、あまり見栄えはよくない
    これは研究者への批判という意味ではまったくない
  • アップストリームに送った issue 報告もこんな感じだったのかは分からないが、かなり追いづらかった
    KDE や Flatpak の内部構造にもっと慣れていれば、ずっと理解しやすかったと思う