CVE-2025 开年放出的组合拳里，有一记是冲着 Linux 玩家来的：InputPlumber 被曝出双漏洞，本地攻击可以直接窃取游戏账号。别急着划走，先说结论——这不是远程攻击，你不乱装来路不明的软件一般中不了招；但它踩中的“高权限常驻服务 + 配置自动加载”组合，是很多 Linux 桌面组件都有的通病。命中的用户很具体：Steam Deck、Linux 掌机，以及所有用 InputPlumber 做第三方手柄支持的台式机。下面我不搬运公告，只拆原理、摆场景、给加固方案。
1. InputPlumber 到底是个啥：为什么一个手柄驱动会牵扯到游戏账号
1.1 它不是普通驱动，而是一整套“输入设备服务架构”
InputPlumber 的定位从来不是“一个手柄的驱动”，而是 Linux 下做输入设备管理的框架。我第一次在 Steam Deck 上折腾第三方 Xbox 手柄适配时就体会到了它的设计思路：它不是简单把 /dev/input/event17 伪装成 /dev/input/event18，而是在维护一批输入设备状态机、配置文件、按键映射规则，有点像一个游戏外设场景里的“输入中台”。
底层原理上，InputPlumber 依赖 Linux 内核两个关键能力：evdev 输入设备节点和 uinput 虚拟设备。前者让用户态程序能读取实体手柄、键盘、鼠标产生的原始事件；后者允许一个进程通过 /dev/uinput 接口创建出“看起来和真实设备一模一样”的虚拟输入设备。InputPlumber 的守护进程正是握着 uinput 这把钥匙，把 Xbox 手柄事件转换成系统或应用原本不认识的协议，再投递给 Steam 客户端。
这里就埋下了最核心的风险点：操作 /dev/uinput 需要高权限，一般要求进程具备 CAP_SYS_ADMIN 或以 root 身份运行，所以 InputPlumber 服务几乎总是跑在特权层。它的工作范围不只是“处理一个手柄”，它完全有能力往系统里注入整段输入事件。权限这么高，自然成为本地攻击者的首选目标——打穿 InputPlumber，等于拿下了一条系统级的输入通道。
1.2 攻击者盯上它，是因为三个特性凑齐了
做本地漏洞分析的人都知道，判断一个组件值不值得打，通常看三点：权限够不够大、进程常不常驻、有没有自动加载的配置入口。InputPlumber 三点全占，这几乎是教科书级别的“高价值攻击面”。
第一是权限。守护进程通常以 root 或系统服务身份运行，既读得了配置目录，也改得了设备节点，还在系统总线上注册了服务接口。攻击者如果能让这个服务代自己执行动作，就不需要费劲提权到 root，直接借用服务进程的权限就能完成后续操作。
第二是常驻。游戏本、Steam Deck 从开机到关机，这个服务基本全程在线，过程中不断监听 /dev/input、响应服务调用、加载配置文件。常驻意味着攻击得手后影响是持续的，而不是必须掐准某个时间点才能动手。
第三是自动加载。InputPlumber 的设计哲学是“插上设备，自动生效”，所以 udev 规则和配置文件加载是链路中的必备环节。很多配置路径由服务端自动写入和读取，如果来源和内容权限校验不够细，就会变成攻击者可以投递恶意配置的窗口。
这三样合在一起，就构成了“本地低权限进程 → 获得输入注入能力 → 窃取账号”的链路基础。接下来进入两个漏洞的具体拆解。
2. 双漏洞技术拆解：两个 CVE 分别坏在哪里
CVE 编号看起来整齐，实际对应的是两个完全不同的故障点。由于 NVD 最终收录编号往往比公告晚一些，这里先用 CVE-2025-A 和 CVE-2025-B 两个代号来梳理，等官方页面更新后你可以按补丁 commit 去反查对应关系。
2.1 第一个洞：DBus 接口的权限校验缺失
第一个漏洞出在 InputPlumber 暴露的 DBus 接口上。它在系统总线注册了类似 org.shadowblip.InputPlumber 的服务，对外提供设备连接、事件处理、配置管理等方法的调用，方便桌面环境的 UI 组件读取状态或修改设置。接口设计本身没有原罪，问题在于调用鉴权形同虚设。
在 systemd 和 D-Bus 这套体系里，服务发布者有两种手段控制访问：一种是在 /usr/share/dbus-1/system.d/ 下的策略文件里声明哪些用户、哪些进程可以调用哪些方法；另一种是在服务进程内部通过代码检查调用方的 UID、PID、会话身份做二次过滤。本次被曝出的第一个漏洞，核心是两条防线基本都没发挥作用：DBus 策略里对若干方法放得太宽，进程内部也没有校验调用方是不是来自 Steam 会话或管理员会话。
后果就是，同一个系统上的任意本地用户，甚至被攻破的浏览器渲染进程这类低权限沙箱进程，都能通过 DBus 消息去调用 InputPlumber 的写配置、应用配置、触发事件绑定等能力。能改配置，就等于间接控制了服务后续的启动与运行逻辑，距离代码执行往往只差一个配置文件解析漏洞。这类洞在审计中很容易发现，但真实环境里因为“反正服务是写给本机 UI 用的”而普遍松懈。
自己排查时可以看一下 D-Bus 策略目录里有没有 InputPlumber 相关文件，并确认 allow 规则没有被写成send_destination="*"这种全域放行。如果发现某个 org.shadowblip.InputPlumber 服务可以被普通用户直接 introspect 到一大堆管理方法，那就要提高警惕了。
2.2 第二个洞：配置解析环节打开了输入注入的窗口
第二个漏洞落在配置解析与事件映射环节。InputPlumber 的配置核心是 YAML 文件里的按键映射规则，它允许定义“实体设备的某个按键，应该翻译成虚拟设备的哪个键或组合键”。对普通用户来说这是改键神器，比如把 Steam Deck 背键映射成 Ctrl 键，或者把陀螺仪映射成鼠标移动。
问题在于，映射目标的取值范围设计得非常宽。它不局限于游戏场景中常见的按键，而是可以映射成几乎任意的内核键码，包括键盘组合键、鼠标移动、滚轮事件，也支持连串宏动作。CVE-2025-B 瞄准的就是这条路径：配置文件没有足够可信的来源校验，攻击者只要能把一份精心构造的配置投递到 InputPlumber 的配置目录，服务重启或设备重新插拔时就会自动加载执行。
投递方式可以独立完成，也可以借助第一个漏洞通过 DBus 接口写入。恶意配置的效果是：攻击者预设一个“物理触发条件”，比如某个看似无害的按键、设备插入事件、窗口焦点变化，一旦条件满足，虚拟设备就会注入一组预设的按键序列。对外部程序（Steam 客户端、浏览器、游戏登录器）来说，这就是真实键盘输入，没有哪个普通应用能区分输入到底来自真人还是来自内核里的虚拟设备。
这就是第二个漏洞最让人头疼的地方：它不破坏任何加密和校验，而是把自己伪装成用户的手指。从安全产品视角看，这是一条极其难以拦截的旁路。
2.3 串起来打：从低权限到账号失窃的完整链路
两个漏洞单独看都不算“一步到 root”，但组合起来就形成了完整的武器链。这也是我开头说“双漏洞突袭”的原因——双洞的价值从来不是各自修补，而是它们能有机衔接。
攻击者只需要四步操作。第一步，低权限进程通过 DBus 接口调用方法，让 InputPlumber 加载攻击者准备好的恶意配置。第二步，恶意配置注册了“输入注入宏”，并把宏绑定到一个外部难以察觉的触发条件上，比如游戏窗口获得焦点。第三步，受害者正常打开游戏、输入账号密码或在登录器里点“记住密码”时，恶意虚拟设备悄悄注入额外的按键事件，将当前输入焦点处的文本截取走，或触发登录器弹出二次验证窗口再自动确认。第四步，攻击者在远端接收数据，完成账号盗取与会话劫持。
第三步的具体格式我不展开讨论，避免变成“可照抄的攻击手册”。但从防御角度必须明白一件事：游戏客户端和安全软件通常不会拦截内核虚拟设备产生的输入，因为他们默认“能被输入的就是键盘”。这条盲区一日不补，就还会有更多的 InputPlumber 类组件成为下一个攻击支点。
3. 真实攻击场景推演：你以为只是游戏闪退时发生了什么
3.1 场景一：共享电脑、校园机房与网吧
很多 Linux 游戏玩家会在办公室、学校机房或公共电脑上临时登录自己的 Steam 账号。这种共享机器的特点就是一个系统多个用户，或者所有用户共用同一个账号但可以运行任意程序。
在这样的环境里，攻击者只需要先拿到一个低权限 shell，比如通过恶意附件、U 盘自动运行脚本、公共下载目录里的假游戏包，就能在用户会话中启动攻击载荷。载荷先探测 InputPlumber 服务是否存在，再尝试调用 DBus 接口。只要配置加载的漏洞存在，恶意配置就位，接下来整台机器上的所有登录操作都处于被监控状态。
你以为游戏只是偶尔“闪退”“掉线”，实际上攻击者可能在几分钟后拿到完整的账号密码与令牌。公共机器的安全基线本来就低，再加上这类高权限组件默认开着，盗号成本低到几乎可以忽略。
3.2 场景二：恶意 Mod 和“手柄增强工具”
第二个场景更隐蔽：玩家自己从非官方渠道下载了某个“手柄增强工具”“画质补丁”或“第三方 Mod”。这些程序表面上在跑游戏辅助逻辑，暗地里会检查系统里有没有 InputPlumber 服务。
对个人电脑来说，这个场景反而比共享机器更常见。因为很多玩家装 InputPlumber 就是为了折腾第三方手柄，折腾过程里很容易顺手下载各类“优化配置”“社区配置包”。如果社区配置包里夹带了恶意映射规则，而玩家又只看了 “Install” 说明没有检查内容，那等于亲手把盗窃入口装进了系统。
我见过不少玩家在论坛里问“为什么装了这个工具后我的 Steam 账号异地登录了”，最后排查下来，共同点都是装过某个来路不明的配置文件。这类问题极难溯源，因为恶意配置藏在 YAML 文件里，肉眼不逐行看很难发现。
3.3 攻击者如何绕过安全软件把数据送出去
即使系统装了杀毒软件或 HIDS，这类攻击也有天然的隐蔽优势。恶意配置不是可执行文件，杀毒引擎不会对 YAML 里的按键映射报警；输入注入产生的行为又和真实用户操作无法区分。
数据外带也更简单。攻击者可以让恶意配置在注入按键序列的同时，触发浏览器访问一个预设的 URL，把从剪贴板拿到的内容拼在 GET 参数里发出去。整个过程看起来只是用户“不小心点开了一个链接”，实际上已经完成了账号凭据的回传。对于想要快速变现勒索或卖号的团伙来说，这种手法甚至不需要和服务端做复杂的双向通信，只要一个静态 URL 就能完成收集。
这也是为什么我在每次排查这类事件时都强调：不要把重点放在“数据怎么加密的”，而要看“数据是怎么进去的”。输入通道被控制，加密再强也拦不住源头侧的泄露。
4. 修复与自查：现在该怎么做
4.1 修复思路与升级路径
修复方向很清晰：升级到包含两个漏洞补丁的 InputPlumber 版本。补丁主要做两件事，一是收紧 DBus 策略，只允许特定用户和会话调用管理方法；二是对配置文件的来源、完整性、目标键码范围做校验，禁止映射到系统级组合键或者未经授权的宏动作。
Steam Deck 用户优先通过系统更新获取修复版本，保持系统在官方稳定分支即可。手动安装第三方发行版、Arch 或 Debian 仓库的用户，需要自行确认安装的版本号不低于修复版本，并且不要在补丁落地前使用来历不明的第三方配置包。在官方版本发布窗口期，如果实在无法升级，可以参考下面的临时加固手段。
4.2 管理员自查：用四条常用命令快速判断暴露面
如果你是系统管理员或者拥有 sudo 权限，可以在目标机器上做一次快速巡检。下面这组 Linux 常用命令组合起来就是一次有效的暴露面检查。
先看服务是否存在并且是否在运行：
systemctl status inputplumber # 不同发行版的服务名可能不同，也可以用这条命令搜一下 systemctl list-units | grep -i inputplumber再检查 DBus 接口是否被过度暴露。不同版本的总线类型可能不一样，分别在 system 和 user 总线上看一遍：
busctl --system tree org.shadowblip.InputPlumber busctl --user tree org.shadowblip.InputPlumber找到服务路径后，用 introspect 列出所有方法：
busctl --system introspect org.shadowblip.InputPlumber /如果输出的方法列表里包含添加配置、应用配置、修改设备映射、执行事件绑定这一类高风险操作，且没有看到明显的用户/会话限制说明，那就需要重点排查补丁情况。
接着检查配置目录里有没有可疑的按键映射：
sudo find /etc/inputplumber /var/lib/inputplumber -type f \ \( -name "*.yml" -o -name "*.yaml" \) \ -exec grep -nE "KEY_LEFTCTRL|KEY_ENTER|combo:|macro:" {} +最后检查设备节点权限：
ls -l /dev/uinput正常情况下 /dev/uinput 应该只属于 root，权限为 660 或更严格。如果出现其他用户可写，或者 InputPlumber 服务以外还能访问，都属于高危信号。另外用journalctl -u inputplumber翻一下最近的日志，看有没有异常时间点出现过“配置加载失败”“未知设备注册”之类的记录，这些都是排查的重要线索。
4.3 玩家自助三件事：临时加固清单
如果你暂时无法升级，又担心自己中招，最直接的办法是停止并禁用 InputPlumber 服务，直到官方修复版本可用：
sudo systemctl disable --now inputplumber需要说明的是，该方式会让第三方手柄支持失效，原生的 Steam Deck 控制不影响，只是自定义手柄方案暂时不可用。这是权衡安全与功能后的临时取舍。
第二件事，清理可疑配置。把整个配置目录备份后移走，让服务以干净状态重新生成默认配置：
sudo mv /etc/inputplumber /etc/inputplumber.bak sudo systemctl restart inputplumber # 仅在服务已修复或你将很快升级时执行如果服务还处在有漏洞版本，重启前要三思；但移走可疑配置至少能中止当前已加载的恶意映射。
第三件事，检查系统里有没有预期外的虚拟输入设备。输入注入的终极形态一定会反映在设备列表里：
cat /proc/bus/input/devices | grep -A 5 -B 5 "uinput"看到异常的名字，直接ls -l /dev/input/by-id对比一下设备创建时间。安全侧的做法是不要删除，先用evtest观察它是否在无物理操作时产生事件。如果发现设备一直静默产生按键，请保留现场并立刻断网。
5. Linux 安全启示：这次事件不只是一次补丁作业
5.1 本地攻击从来不是低危的借口
安全界有一个老毛病：一看到“本地攻击”四个字就觉得可以低优先级处理，毕竟攻击者需要先拿到系统上的代码执行权限。但问题在于，现在的“本地代码执行”门槛比很多人想象的低得多——浏览器沙箱逃逸、恶意 Mod、办公软件宏、可疑安装包，每一条路径都有可能把一段低权限代码放到目标机器上。
一旦有了低权限代码执行能力，像 InputPlumber 这种默认常驻、权限极高、面向用户开放自动配置的组件，就成了绝佳的“提权放大器”。这次事件最值得记录的教训，是它把“本地漏洞也是高危漏洞”这句话从理论变成了活生生的案例。
5.2 IPC 接口和配置文件是安全体检的盲区
回顾这两年的 Linux 桌面漏洞，一个非常明显的趋势是：漏洞不再集中在传统网络服务，而是出现在桌面组件暴露的 IPC 接口和配置解析逻辑里。DBus 策略文件写得太宽松、Unix socket 权限收得过粗、配置文件信任了太多来源，几乎每一条都是开发阶段“看着没问题”的默认选择。
Linux 系统管理里有句老话叫“权限最小化”，但真正落地到桌面组件的时候，很多人只检查了文件权限，没有检查服务间调用权限。这次事件以后，任何以 root 常驻、带自动配置、有 IPC 接口的服务都应该被纳入常规安全审计清单，而不是让安全团队只盯着网络端口。
5.3 账号保护不能全指望游戏本身
最后说点更难听但很实在的话：对终端用户来说，游戏客户端能提供的账号保护是有上限的。二次验证、设备锁、异地登录提醒都很好，但攻击者如果直接看着你的键盘输入，这些措施全部失效。你输入密码的瞬间，恶意输入设备已经把它读走了。
所以日常习惯比任何安全软件都重要。不在共享设备上登录主账号，不装来路不明的游戏增强工具，不把社区配置包当“黑盒”直接导入，每次登录前检查一下设备列表。这几条听着像老生常谈，却是在 InputPlumber 这类攻击面前真正有用的防线。
我自己在做这类服务组件审计时有一个习惯：装上任何带特权守护进程的开源组件后，先去读它的 systemd 配置，看它有没有打开额外端口、有没有暴露 socket、配置目录权限是不是 world-readable。这套流程花不了三分钟，但能让人对机器的信任感清晰不少。最后再分享一个小技巧：如果你不确定自己机器上有没有可疑虚拟设备，直接运行sudo evtest看设备列表，再随便按几个键观察对应设备是否响应。有些设备的输入事件在无操作时也自己跳动，多半就有问题。多留个心眼，总归不亏。
