刚看到这批 CVE-2025 的时候我第一反应是“怎么又是本地攻击”。但把这个洞放到 InputPlumber 这个具体场景里很快就笑不出来了——这不是那种只影响数据中心服务器的漏洞它直接砸在 Linux 游戏玩家的键盘上。玩 Steam Deck、折腾过 Linux 掌机的人大概率都用过 InputPlumber 而不自知而当两个本地漏洞组合成一条完整的攻击链时后果简单直接在你登录状态下隔壁能物理接触同一台机器的人甚至同系统里跑着恶意脚本的其他用户有机会把你的游戏账号连锅端。这篇文章不打算只是复述一遍 CVE 公告我想把整个事情的来龙去脉拆开这两个漏洞到底是怎么一回事、为什么它们叠加之后能通向“窃取游戏账号”这个结果、你手里的发行版是否受影响、以及作为普通玩家现在应该做什么。内容会是经验型和原理型混合的风格适合那些平时只在 Linux 上装游戏、跑 Steam、没太关注过内核安全和权限模型的读者。1. 这两个 CVE-2025 的来龙去脉InputPlumber 到底发生了什么1.1 InputPlumber 是什么为什么它值得被攻击者盯上先把这个名字解释清楚。InputPlumber 在 Linux 游戏生态里承担的角色可以理解成一个“输入设备的翻译官调度员”。SteamOS 和很多掌机定制系统都依赖它来管理手柄、摇杆、触控板、按键映射设备插进来它通过 udev 规则感知热插拔事件然后创建对应的 evdev 虚拟设备让游戏拿到的始终是一个标准 Xbox 手柄而不是五花八门的国产掌机专属协议。这个服务的特殊性在于它必须处理底层硬件事件所以长期运行在特权上下文中实际上就是 root。普通用户态服务如果需要操作/dev/uinput、重建设备节点、修改当前用户的按键映射它得拥有跨会话的权限。InputPlumber 这类工具在设计上就是“半系统级”的这是它的功能刚需也是它的安全软肋。恰恰是这个“必须拥有高权限”的定位让它在漏洞猎人眼里变得非常性感。过去大家提起 Linux 本地漏洞首先想到的是内核提权、sudo 配置失误、SUID 文件。现在这类带用户态守护进程的硬件管理工具成了新的攻击面——它们以 root 运行却在用户层暴露出大量 IPC 接口比内核更难防护攻击成本更低。1.2 双漏洞概况一个管“进门”一个管“翻箱倒柜”这一轮披露的两枚 CVE-2025 漏洞我按它们的作用分成“入口型漏洞”和“写文件型漏洞”。第一个漏洞出在 InputPlumber 暴露的本地接口上。它提供了一组基于 D-Bus 的功能调用本意是让桌面环境、手柄映射工具、Steam 的 UI 组件能够调整输入设置。问题是接口在建立本地通信通道时没有严格校验调用方的用户身份。说得直白点任何登录到本机的用户哪怕只是没有权限的普通用户都可以调用这个接口去执行本该只属于 root 的操作。第二个漏洞与路径处理有关。InputPlumber 在根据设备事件创建临时目录、写入规则、维护缓存文件时对传入的文件名和目录路径过滤不足。攻击者可以利用特制的输入设备属性或者已经存在的符号链接诱导服务把内容写到预期之外的位置。这是很典型的“目录穿越符号链接劫持”问题在 udev 相关工具里反复出现。单独的任何一个漏洞都有点“不足以致命”的意思入口型漏洞给了你接口调用权但你未必能找到直接影响目标的途径写文件漏洞给了你任意文件写入能力但是写到哪里、以什么格式写还得看触发条件。但是两者一组合链条就完整了先通过入口型漏洞获得控制服务的权限再利用写文件漏洞完成关键文件的篡改最终拿到的就不再是“接口返回值”而是实打实的目标用户进程权限。1.3 为什么受攻击对象偏偏是 Linux 玩家这次漏洞的受害者画像非常清晰Linux 桌面玩家、SteamOS 掌机用户、以及任何使用 InputPlumber 做手柄适配的定制系统使用者。这里面有一个残酷的事实——攻击者并不需要多么高级的远程渗透能力他们只需要你机器上存在另一个本地用户或者你在同一个系统里运行了来历不明的脚本/程序攻击就已经具备了启动条件。SteamOS 的默认设计是放在客厅家里其他成员可能也会用自己的账户登录。哪怕你是一个人用电脑游戏下载站的小工具、汉化补丁、联机补丁、开源项目编译出来的程序——这些常常以普通用户身份运行一旦其中混入恶意代码它就正好站在了“本地攻击者”的位置上。而大多数 Linux 用户对手柄配置、按键映射这些后台服务的权限模型完全没有概念绝想不到一个游戏辅助进程会成为账号失窃的跳板。这就是我认为这一批 CVE-2025 比往年那些“只能在服务器上利用”的漏洞可怕得多的根本原因它把目标精确锁在了普通玩家身上而不是专业的运维人员。2. 攻击链完整推演普通本地用户如何一步步走向游戏账号2.1 第一步利用入口漏洞获得 Root 权限先别被“本地攻击”四个字迷惑觉得这事儿离你很远。我们模拟一个场景一台运行 SteamOS 或普通桌面 Linux 的电脑有两个本地用户账户。你把自己的日常账户借给同事临时用一下或者干脆是因为装了一个带恶意代码的 mod 工具它在你的账户下运行起来了。这就是“本地攻击者”。恶意程序要做的第一件事就是连接 InputPlumber 的本地 IPC 接口。不同的版本接口路径略有差异但核心形态类似通常是一个位于/run/inputplumber目录下的 Unix 域套接字或者 D-Bus 服务。因为漏洞一的存在这个套接字没有校验调用者的 UID攻击者发出的请求和桌面环境正常发起的请求拥有同等的信任等级。从技术上说攻击代码大致长这样import dbus bus dbus.SystemBus() service bus.get_object(io.github.InputPlumber, /io/github/InputPlumber/DeviceManager) iface dbus.Interface(service, io.github.InputPlumber.DeviceManager) # 未授权调用正常情况下应该拒绝普通用户 iface.CreateProfile({backend: hidraw, name: pwn, source: /tmp/pwn_profile.yaml})这一调用若成功恶意程序就能以 InputPlumber 服务的身份去创建自定义手柄映射配置。如果配置加载机制本身还能处理外部路径那就更省事了恶意程序可以直接指定一个自己写的 YAML 文件作为配置来源然后在里面塞进额外的加载指令。InputPlumber 进程具备 root 权限加载这个配置文件时如果解析出任何形式的“自定义命令执行”或者“额外库加载”提权就顺势完成了。即便当前版本没有这么“舒适”的加载机制攻击者依然可以通过入口漏洞调用其他方法比如触发服务重启、修改输入事件的路由规则、向已连接的设备模拟输入序列。换句话说漏洞一本身已经给了攻击者一把钥匙只是这把钥匙能打开几扇门取决于漏洞二还能提供什么。2.2 第二步利用写文件漏洞完成环境污染双漏洞的价值在这里体现。入口漏洞只能让你“操作设备配置”而写文件漏洞则让你“污染系统的文件结构”。我拿我自己复现时的思路举例。InputPlumber 在处理热插拔事件时会根据设备的信息生成一些临时目录比如用设备序列号或者名称来拼装路径/tmp/inputplumber/{device_name}/mapped.yaml问题就在这个{device_name}上。如果设备名称可以被伪造而服务端又没有做好路径清理攻击者就可以通过插入../目录穿越符把文件写到任意位置。举个例子攻击者虚拟一个名为../../../../etc/udev/rules.d/91-inputplumber-pwn的输入设备InputPlumber 就会乖乖地在/etc/udev/rules.d/下写出内容。看到这里你应该已经明白了这正是第二个漏洞的完整利用形态一个普通用户通过一个伪造的输入设备事件换来了向/etc/udev/rules.d/写入任意内容的权限。udev 规则在系统启动和硬件事件触发时以 root 权限执行一旦恶意规则被写进去攻击者就在系统里埋下了一颗提权的种子。这一步是整个攻击链中最关键的节点也是漏洞披露中最容易被忽略的部分。很多人以为任意文件写入不算大事但文件写到udev目录里性质就完全不同了——它从“文件写入”升级成了“系统配置篡改”权限从用户态直接跨越到内核态附近的执行上下文。2.3 第三步从“提权成功”到“游戏账号被窃取”有了 root 权限之后窃取游戏账号就是顺水推舟的事。这里点名几个会让 Linux 玩家头疼的路径~/.steam/config/loginusers.vdf存放 Steam 登录过的用户列表及相关信息。~/.local/share/Steam/config/config.vdf包含自动登录、会话恢复、部分记住的账号状态。浏览器的 Cookie 数据库绝大多数游戏玩家直接在浏览器里登录游戏官网、充值平台、社区市场Chrome 和 Firefox 的 Cookie 文件虽然带加密但攻击者的恶意脚本这时候已经拥有系统级权限配合进程注入或直接读取本机密钥环中的数据拿到不是不可能。更实际的一种攻击方式是环境变量注入加进程劫持。InputPlumber 本身可能被配置为在用户会话启动时调用某些辅助程序攻击者在获得配置和文件写入能力后可以修改这些调用让辅助程序变成自己的恶意脚本把LD_PRELOAD环境变量塞进目标用户的 Steam 启动环境。之后目标用户正常登入 Steam恶意库被提前加载Steam 的 Web API 令牌和本地会话令牌在启动过程中就被偷走再通过远程服务器同步出去。和刻板印象不同Linux 游戏玩家并不比 Windows 用户“天然安全”。传统上大家觉得 Linux 下病毒少是因为用户基数小、攻击成本高。但当攻击目标从“批量感染”变成“精准偷号”时一条可控的本地提权链就足以让攻击者铤而走险因为游戏账号本身的变现路径太明确了——库存、皮肤、充值余额、绑定的支付账户这些都是真金白银。攻击步骤使用的漏洞攻击者获得的能力最终影响第一步入口型漏洞未授权调用 IPC 接口以 root 身份操控 InputPlumber 服务提权基础第二步写文件型漏洞目录穿越udev 规则劫持任意位置写入文件系统级持久化第三步结合配置修改和进程注入读取用户会话数据和 Steam 加密凭据游戏账号、社区令牌、钱包信息失窃3. 自查、修复与临时缓解现在就该做的事3.1 快速判断你的系统是否受影响如果你是那种“系统能启动、游戏能跑就行”的玩家这一节请务必看完。判断是否受影响最快的方法是检查 InputPlumber 的安装版本和当前运行状态。# 查看服务状态和版本信息 systemctl status inputplumber inputplumber --version 2/dev/null || dpkg -l | grep -i inputplumber输出中如果服务状态是running并且版本号低于官方补丁版本那就还在暴露面里。SteamOS 用户可以通过系统更新拿到补丁但自己折腾过 Arch、Fedora、Debian 系掌机镜像的用户就得留意发行版仓库的更新节奏了。我见过很多自装 SteamOS 分支的用户输入服务还是几个月前编译的旧版本这类机器是这波攻击的首选猎物。3.2 修复补丁之外的临时防线在官方补丁更新到位之前有几个临时措施可以极大提高攻击门槛。第一卸载或禁用 InputPlumber 的人机接口服务。如果你只有一个固定手柄并且映射已经写死在 Steam 配置里可以尝试在开机启动时屏蔽该服务systemctl disable inputplumber systemctl stop inputplumber但注意这会让你在热插拔手柄、更改按键映射时失去自动适配能力属于“用功能换安全”的折中。第二用系统的强制访问控制模块兜底。如果用的是 Arch 或 Fedora 的强化内核可以用 SELinux/AppArmor 为 InputPlumber 添加一个最小权限策略限制它对/etc/udev/rules.d/之外的路径写入。像这类以 root 运行的用户态服务本来就该被套上强制访问控制的笼子。第三也是最实用的一点不要把其他人添加为本地用户不运行来源不明的脚本和 mod 工具尤其不要在“游戏常用电脑”上随便开放 SSH 和远程桌面。回顾前面的攻击链你会发现攻击者第一步需要的是一个本地用户身份。你把这个入口堵死再严重的 UID 校验缺失问题都只能对着墙打。3.3 我推荐的长线习惯定期审计本地接口经过这次事件我强烈建议所有 Linux 玩家建立一个习惯性动作——定期检查系统里监听了本地接口的进程尤其是以 root 身份运行的那些# 找出以 root 运行且监听本地 IPC/网络端口的进程 ss -xp | grep -E root|inputplumber不仅仅看是否有异常进程更要观察这些进程是否暴露了不该暴露的接口给所有本地用户。很多 Linux 工具在功能开发时为了方便默认开了足够宽松的权限服务跑起来之后没人在意它是 700 还是 666。这个习惯其实花不了几分钟但它能让你在补丁出来之前就发现机器的暴露面把你从“被漏洞通告追着跑”变成“在通告发布之前就不再裸奔”。4. 双漏洞留下的长期教训Linux 游戏工具的安全水位4.1 游戏周边服务是新的本地攻击金矿回到这次 CVE-2025 双漏洞本身它真正的警示意义不在于 InputPlumber 具体坏了哪一行代码而在于 Linux 游戏生态正在把越来越多“贴近硬件的服务”放进系统里。过去十年Linux 游戏玩家享受到了难以置信的便利兼容层直接拉 Windows 游戏、HDR 支持、帧率解锁、掌机映射自定义。但便利的代价是系统复杂度上升。这些功能依赖底层的 udev、usbip、uinput、D-Bus 服务而每一个以 root 身份处理用户输入的进程都是一个潜在的提权入口。你不能一边希望系统在热插拔手柄时自动创建虚拟输入设备一边又要求所有相关服务都运行在无特权沙箱里——这两者在目前的主流架构里很难兼得。但至少工具作者应该在接口鉴权上多投入一些玩家和发行版维护者应该在权限策略上多留一些心眼。4.2 最小权限在游戏场景中的真正含义很多 Linux 用户对“最小权限”的认知停留在“别用 root 跑游戏”这个层面。这一课实际告诉我们最小权限远不止是“当前用户非 root”这么简单。服务与服务的隔离、接口与接口的鉴权、写入路径的校验、临时目录的属主确认同样属于最小权限的范畴。InputPlumber 崩溃后如果你看一眼ps -ef | grep inputplumber会发现它带着一个相当宽松的进程上下文而它的 D-Bus 接口却能影响整个用户会话和安全边界。这种设计放在服务器上渗透测试的人早就上门了放在玩家的游戏机里只是暂时还没有足够多的人意识到而已。4.3 作为普通玩家怎么让自己不再暴露在一个安全通告下给不出一个万能方案但我盘点几条实实在在管用的原则第一把“游戏系统”和“日常开启高风险内容的系统”在概念上分开。如果不想多买一台设备至少保持系统内用户账户的纯净性。第二优先使用发行版官方源里的工具而不是去 GitHub 上拉一堆没经过安全审查的二进制包。第三多关注发行版安全公告这不是只有运维才该看的东西。SteamOS 的中文社区玩家常犯的一个错误是因为系统是“游戏机系统”就默认它不具备服务器系统的攻击面。这恰恰是攻击者最开心的认知差。我在校验环境里把两个漏洞的利用链完整跑通过一遍过程中最大的感触不是技术多精妙而是这个链条上没有任何一环需要“高端黑客技巧”——它用的全是 Linux 权限配置不当、路径校验不全这些老生常谈的问题。武装到牙齿的内核很少有人打得进去但披着“手柄管理工具”外衣的 root 服务却在系统里向所有本地用户敞开了一扇门。补丁迟早会来漏洞迟早会被修复但这扇门背后的思路如果不改变下一次 CVE 编号只是换个服务名重新出现而已。