ファイル通知システムのサイドチャネル漏洩:Linux・Android・Windows・macOS

ファイル通知システムには Linux、Android、Windows、macOS のいずれにもサイドチャネル漏洩がある。読み取り権限だけの攻撃者がファイルイベントを監視して、利用者の操作を復元できる。

日本語
コピー
论文首页的示意图:文件系统事件像信号一样从窗口边缘泄漏出去

ACM Conference on Computer and Communications Security(CCS) に採録、2026 年 11 月 15–19 日 — オランダ・ハーグ


插图

ファイル通知システムは、ファイルが変化したとき——たとえば開かれた、閉じられた、書き込まれた、削除された——にアプリケーションへ通知する。攻撃者はあるファイルやディレクトリに対する読み取り権限だけで、こうした通知を監視しユーザーの行動を復元できる。私たちは Linux、Android、Windows、macOS のすべてで同種の共通した問題を発見した。うち三つは深刻で、それぞれ特定のプラットフォームにのみ現れる:

  1. Linux では、読み取り可能なディレクトリを監視すると、そのディレクトリ内のファイルで起きたすべてのイベントが報告される。攻撃者が直接読み取れないファイルであっても例外ではない。最も深刻なケースは /dev/input に関わる。後述の「キー入力間隔のタイミング」を参照。

  2. Android では、FileObserver が FUSE 層のアプリごとのストレージビューを迂回し、非特権アプリが別のアプリのプライベートディレクトリを監視できる。私たちは WhatsApp でこれを実証し、写真・動画・ファイルがいつ届き、いつ削除されたかを正確に把握できることを示した。後述の「私的な通信の漏洩」を参照。

  3. Windows では、ルートディレクトリ(C:\)を監視すると、システム上のどこであれアクセスされたファイルの完全なパスが、権限に関係なく報告される。ユーザーをまたいでも 🙂。Microsoft はこれを ✨未公開の機能✨ と見なしている。私たちが見つけた最も深刻なケースは、別のユーザーがどのウェブサイトにアクセスしたかをリアルタイムで漏洩させるものだ。後述の「ウェブサイト閲覧の直接漏洩」を参照。この発見により、Microsoft は Pwnies Award 2026 の最悪のベンダー対応賞にノミネートされた。

Link


Linux では、ファイル通知サブシステムは inotify と呼ばれ、カーネル 2.6.13(2005 年)以降、ユーザーをまたぐアプリケーションがファイルやディレクトリに監視を設定できる。

Android では、このサブシステムは FileObserver クラス(2008 年以降)と呼ばれ、inotify の上に被せた薄い Java ラッパーだ。

Windows は ReadDirectoryChangesW という Win32 API を提供しており、Windows 2000 から利用できる。この API を使えば、ユーザーをまたぐアプリケーションがディレクトリに監視を設定し、そのディレクトリやディレクトリ内のファイルに対する操作の通知を受け取れる。dotnet では、 FileSystemWatcher クラスが ReadDirectoryChangesW に接続している。

macOS では、File System Events API によって、監視対象ディレクトリ内のファイルがいつ変化したかをアプリケーションが知ることができる。この API は Mac OS X Leopard 10.5 版(2007 年)から存在する。アーカイブは Apple Developer Connection の Leopard OS Foundations Overview を指している。


デモ

ここからは四つの興味深いケーススタディを示す。最初の二つは Linux:キー入力間隔のタイミングと、認証画面のなりすまし。三つ目は Android、四つ目の動画は Windows で、ウェブサイトを直接漏洩させる。

どのシステムでも押さえておくべき要点は一つ:これらのファイルの中身は分からない。得られるのはファイルに関する通知だけであり、それだけでユーザー・システム・アプリケーションの行動を漏洩させるのに十分だと示す。場合によっては、従来は存在すら知りようがなかったファイルの存在も分かる。


1. Linux:キー入力間隔のタイミング

Linux では、読み取り権限のないファイルに inotify の監視を設定すると権限拒否エラーになる。しかしそのファイルの親ディレクトリが読み取り可能なら、そのディレクトリを監視することで、そのファイル上で起きたすべてのイベントが報告される。

つまり、ユーザーが /dev/input/event4 を読めない場合、ファイルに inotify の監視を追加すると権限拒否エラーになる。だがユーザーが /dev/input を読める——すなわちディレクトリ内のファイルを一覧できる——なら、ディレクトリに inotify の監視を設定することは成功し、その中のすべてのファイルの通知が届く。次のとおり:

図 1. Linux で、監視対象ファイルの親ディレクトリに監視を設定して読み取り権限を迂回する。

このシステムでは、event4 がちょうど一回のキー入力に対応する。漏洩するのはどのキーかではなく、キーが押されたという事実だけである点に注意してほしい。大したことではないように聞こえるかもしれないが、キー入力間隔のタイミング攻撃の研究は 20 年以上にわたって存在する。キーとキーの間の時間が情報を漏らすのだ。たとえば「WindRunner」という単語では、ユーザーは二つ目の「N」を他の文字より速く打ちがちである。指がすでに「N」キーの上にあるからだ。

これには次が含まれる:Song ら(2001)、Zhang と Wang(2009)、Monaco(2018)、そして最近では Qiu ら(2025)。

お使いのブラウザは video タグに対応していません。

動画 2。/dev/input にマウントしたクロスユーザー監視は、キーストロークのたびに通知を受け取る。

異なる2人のユーザーが同じサーバーに SSH でログインしている場合にも、同じ挙動が観察できる。一方のユーザーが /dev/pts を監視していれば、もう一方がキーを押すたびにそれを察知できる。

  • 入力が端末上でテキスト更新を引き起こす場合に限る。pwfeedback を無効にした状態で sudo のパスワードプロンプトに入力しても、通知は発生しない。

お使いのブラウザは video タグに対応していません。

動画 3。ssh サーバー上で、/dev/pts にマウントしたクロスユーザー監視が、キーストロークのたびに通知を受け取る。


2. Linux:認証画面のなりすまし

Wayland 上で動作する KDE Plasma を対象とした認証画面なりすまし攻撃を示す。この攻撃では、同一ユーザーのプロセスが polkit の /usr/bin/pkexec へのアクセスを監視し、認証プロンプトがいつ現れるかを検出する。本物のパスワードダイアログが開こうとした瞬間に、攻撃者はその上に偽のパスワードウィンドウを素早く描画し、ユーザーに資格情報を入力させる。Wayland はそもそも入力の覗き見を防ぐために設計されているが、KDE Plasma セキュリティチームによれば、KDE のフォーカス盗み防止はセキュリティ機構として設計されたものではない。

お使いのブラウザは video タグに対応していません。

動画 4。/usr/bin/pkexec へのアクセスを監視すると、パスワードプロンプトがいつ表示されるかを攻撃者が把握でき、本物のプロンプトの上に偽のプロンプトを描画できる。ここで2つのダイアログの見た目が違うのは意図的なものだ。

SteamOS も KDE Plasma 6 を使っているため、SteamOS 上で KDE ターミナル(Konsole)が認証プロンプトの上に描画された例を挙げる(仮想マシン上での実行なので、実際の状況は異なる可能性がある):

図 5。SteamOS でも KDE Plasma 6 を使っているため、パスワード認証ウィンドウの手前にウィンドウを置くことができる。


3. Android:私的な通信の漏洩

前述のとおり:

Android では、FileObserver が FUSE 層のアプリ単位のストレージビューを迂回し、 非特権アプリが別のアプリのプライベートフォルダを監視できる。私たちは WhatsApp を例にこれを実証し、写真・動画・ファイルがいつ到着し、いつ 削除されるかを正確に明らかにした。

各アプリには /sdcard/Android/ 以下にプライベートフォルダが割り当てられ、Android の FUSE 層によって他のアプリから隠される。この FUSE 層は、そのフォルダを他のあらゆるアプリから見えないようにするはずのものだ。通常、非特権アプリが WhatsApp のプライベートメディアフォルダ(例えば /sdcard/Android/media/com.whatsapp/WhatsApp)に対して File.listFiles() を呼び出すと、カーネルは空のサブフォルダを返し、ファイルは1つも見えない。FUSE 層が WhatsApp のファイルを一覧から完全に除外するため、このフォルダは他のアプリからは空に見える。私たちの研究が示したのは、この保護がファイル通知には及ばないということだ。権限を一切持たない2つ目の非特権アプリが、同じフォルダに FileObserver 監視をマウントし、ファイルを1つも一覧できないにもかかわらず、そこでのファイルイベントを(ファイル名付きで)すべて受け取れてしまう。

WhatsApp の場合、受信したメディアはファイル名を伴う MOVED_TO イベントとして現れる。私たちのログでは、WhatsApp がダウンロードと復号を完了してから約 100ms 後に IMG-20260401-WA0011.jpg が WhatsApp Images/(すなわち .Shared/)へ移動しており、これは概念実証アプリ(きわめて大量)の logcat 出力で確認できる:

左:WhatsApp 上で、同僚の Roland が依頼どおり WhatsApp の画像を送信した。右:その非特権アプリが、新たに受信した WhatsApp の画像を観測した。

送信したメディアは別に保存されるため、攻撃者はその画像が送信されたものか受信したものかも判別できる。画像は WhatsApp Images/Sent/、ドキュメントは WhatsApp Documents/Sent/ にあり、その他の受信コンテンツは親フォルダに残る。ファイル名だけでメディアの種類(画像、動画、ボイスメッセージ、ドキュメント)と作成時刻が分かるので、攻撃者はユーザーが何をいつ送受信したかを再構成できる。ファイルの削除もイベントを発生させるため、後からメッセージのメディアを消したことも観測できる。

4. Windows:ウェブサイト情報の直接的な漏洩

Windows では、読み取り不可のディレクトリに ReadDirectoryChangesW 監視をマウントするとアクセス拒否エラーが返る。しかしルートディレクトリ(例えば C:\)にマウントすればこの制限を回避でき、Windows はシステム全体のファイルシステムイベントを、ファイル名付きで報告する。対象のファイルが読み取り可能かどうかは関係ない。マイクロソフトとの責任ある開示のやり取りの中で、同社はこれを未文書化の機能と見なしていると述べた。

ファイル名が情報を漏らす例として、ブラウザがウェブサイトを訪れたときに作成するディレクトリがある。サイトがローカルストレージ、IndexedDB、キャッシュのいずれかを使っていれば、Firefox はそのサイト専用のディレクトリを作成して使用する。注目すべきは、ディレクトリ名にサイト名が含まれることだ。Firefox では、攻撃者は上位 1000 サイトを安定して監視でき、F1 スコアは 97.8% に達する。

お使いのブラウザは video タグに対応していません。

動画 6. C:\ にマウントされたクロスユーザー監視は、ユーザーが読めないファイルであってもすべてのファイルのイベントを報告する。動画では、攻撃者が「http」でフィルタリングし、別のユーザーが Firefox で arstechnica.com にアクセスしている。

その他の例:

図 7. 左上から時計回りに:lemmy.world、flightradar24.com、 mastodon.social、amazon.de、wikipedia.org、twitch.tv。


チーム

チームはオーストリアの Graz University of Technology 情報セキュリティ教育研究所(ISEC)の研究者で構成されている:

いくつかの Q&A

  1. 自分は影響を受けるか?

Linux、Android、Windows、macOS のいずれかを使っているなら、程度の差はあれほぼ確実に影響を受ける。

macOS はグローバルに読み取り可能なファイルを通じて最小限の情報しか露出せず、プライバシーに関わる情報は漏れない(Linux、Android、Windows とは異なる)。だが、ユーザー、アプリケーション、システムの挙動は依然として追跡可能であり、その程度ははるかに小さい。

  1. 修正策はあるか?

» Linux «

2025 年 12 月、Linux におけるこの問題は部分的に緩和され、特殊ファイル(本質的にはキャラクタデバイスファイルで、/dev/ にあるファイルはほぼこれに該当する)に対して「アクセス」/「変更」イベントを生成しなくなった。この問題を議論し部分的な緩和に協力してくれた Amir Goldstein、Jan Kara、Greg Kroah-Hartman、Linux カーネルセキュリティチームに感謝する。完全な緩和には至っていないが、最も深刻な問題は緩和済みである。この問題には CVE-2025-68788 が割り当てられ、カーネル 5.10.248、5.15.198、6.1.160、6.6.120、6.12.65、6.18.3 で緩和された。

キーボードのキーを押したときに、このコマンドが通知を出すかどうかを確認できる:

inotifywait -m -e access,modify /dev/input

通知が何も表示されなければ(上の動画 2 のように)、そのカーネルには緩和策が含まれている。

» KDE «

KDE セキュリティチームとのメールのやり取りで、彼らはフォーカス窃取の防止はセキュリティ対策ではなく、迷惑なポップアップとの競合状態を避けるためのものだと回答した。

KDE Plasma 5 と 6 で現在有効な方法:

ターミナルを開き、pkexec ls と入力する(どのディレクトリでも構わない)。パスワードウィンドウの上部を右クリック > その他の操作 > 特別なアプリケーション設定を構成 > プロパティを追加 > 他のウィンドウより前面に保つ(+ をクリック)> プロパティウィンドウを閉じる > 「他のウィンドウより前面に保つ」を「強制」に設定して「はい」をクリック > OK。

操作手順の動画:

お使いのブラウザは video タグに対応していません。

動画 8. KDE Plasma 6 でパスワードプロンプトウィンドウを常に他のウィンドウより前面に表示させる。

» Android «

なし

» Windows «

論文を提出してかなり経った後、Microsoft に報告済みであったにもかかわらず、我々は独自に次を発見した:Access check enhancements to prevent unauthorized disclosure of file paths。これは Windows 上での我々の発見、すなわち Sébastien Huneault が 2025 年 4 月に Microsoft へ報告した脆弱性と類似している。Microsoft は新しいレジストリポリシー EnforceDirectoryChangeNotificationPermissionCheck を導入し、我々が報告した挙動を緩和している。このポリシーはデフォルトで無効であり、つまり本稿で報告したすべての攻撃は Windows システム上でそのまま動作する。先にリンクした投稿には、自分のデバイスでこのポリシーを有効にする手順が記載されている。

» MacOS «

なし

  1. どのような情報が漏れる可能性があるか?

どのシステムにも共通する重要な点は、これらのファイルの中身は不明だということだ。漏れるのはファイルに関する通知だけであり、それだけでユーザー、システム、アプリケーションの挙動を暴くのに十分であることは実証済みだ。場合によっては(Windows、Android)、従来は知りようがなかったファイルの存在まで判明する。

なお、ここで示した攻撃には、ローカルのクロスユーザー攻撃者(侵害されたユーザー/システムサービスなど)か、サプライチェーン攻撃を受けたパッケージが必要である。

  1. これらの攻撃はすでに実戦で使われているか?

そのような事例は確認していない。

  1. このロゴを使ってもよいか?

もちろん。ライセンスは CC-BY 4.0 で、SVG と PNG をダウンロードできる。

クレジット表記は以下の通り:

Creator: Brinda Neela
License: CC-BY 4.0
Link: https://inoti.fyi
  1. 概念実証コードはあるか?

ある:https://github.com/isec-tugraz/file-notification-attacks。

謝辞

本研究は European Research Council(ERC プロジェクト FSSec 101076409)および Austrian Science Fund(FWF SFB プロジェクト SPyCoDe 10.55776/F85)の一部支援を受けた。追加資金は Intel からの厚意による寄付である。本論文およびウェブサイトに述べられた見解、知見、結論、提言はすべて著者自身のものであり、資金提供者の立場を必ずしも反映するものではない。

出典: inoti.fyi← ホームへ戻る