隐私安全

文件通知系统的侧信道泄漏：Linux、Android、Windows 与 macOS

文件通知系统在 Linux、Android、Windows 和 macOS 上都存在侧信道泄漏：只有读权限的攻击者能通过监视文件事件，还原出用户打开过什么、编辑了什么。Graz 科技大学的研究团队给出了跨四个平台的实测与成因分析。

inoti.fyiISEC, TU Graz10 分钟阅读

中文
中文日本語
复制
论文首页的示意图：文件系统事件像信号一样从窗口边缘泄漏出去

已被 ACM 计算机与通信安全会议（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 上的跨用户监视器在每次按键时都会收到通知。

当两个不同用户通过 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 的访问情况，能让攻击者得知密码提示何时弹出，从而在真实提示之上绘制一个伪造提示。此处两个对话框的视觉差异是刻意为之的。

由于 SteamOS 也使用 KDE Plasma 6，这里有一张在 SteamOS 上 KDE 终端（Konsole）被绘制在认证提示窗口之上的图片（这是在虚拟机中进行的，因此实际情况可能有所不同）：

图 5。在 SteamOS 上，我们可以将窗口置于密码认证窗口之前，因为它同样使用 KDE Plasma 6。

3. Android：泄露私密通信

如前所述：

在 Android 上，FileObserver 绕过了 FUSE 层的按应用存储视图， 让一个无特权应用得以监视另一个应用的私有文件夹。我们以 WhatsApp 为例演示了这一点，精确揭示照片、视频和文件何时到达或 被删除。

每个应用都会在 /sdcard/Android/ 下分配到一个私有文件夹，通过 Android 的 FUSE 层对其他应用隐藏，而 Android 的 FUSE 层本应让它对每一个其他应用都不可见。正常情况下，一个无特权应用对 WhatsApp 的私有媒体文件夹（例如 /sdcard/Android/media/com.whatsapp/WhatsApp）调用 File.listFiles()，内核返回的是空的子文件夹、没有任何文件。FUSE 层会把 WhatsApp 的文件从列表中完全过滤掉，因此这个文件夹在其他应用看来是空的。我们的研究表明，这层保护并不覆盖文件通知：第二个没有任何权限的无特权应用依然可以在同一个文件夹上挂载 FileObserver 监视器，并收到其中每一次文件事件的通知（连文件名一起），尽管它连一个文件都无法列出。

以 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）的研究人员组成：

一些问答

  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（在哪个目录都无所谓）。右键点击密码窗口顶部 > 更多操作 > 配置特殊应用程序设置 > 添加属性 > 保持在其他窗口之上（点击 +）> 关闭属性窗口 > 将“保持在其他窗口之上”设为“强制”并点击“是” > 确定。

这里有一个视频带你操作：

你的浏览器不支持 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. 我可以使用这个 logo 吗？

当然可以，它采用 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← 返回首页