发条短信就能黑掉服务器？Gammu SMSD曝8.1分命令注入漏洞

## TL;DR - **漏洞**：Gammu SMSD——支撑大量短信网关、告警系统与2FA发送器的守护进程——在收到每条短信时会执行一个由运维配置的钩子（hook）。当启用 Files 后端与 RunOnReceive 时，短信发送者ID被转义后用作文件名，但未针对 shell 进行转义，随后被拼接到 `/bin/sh -c` 命令行中。一个包含 shell 元字符的发送者ID即可触发任意命令执行。 - **影响**：远程、无需认证的代码执行，只需发送一条短信。命令以 `gammu-smsd` 用户权限运行。漏洞类型为 OS 命令中特殊元素未正确中和（CWE-78）。 - **修复版本**：Gammu 1.43.3。安全公告 GHSA-9vjj-v46c-c5qf 于2026年7月25日发布，评级为高危（CVSS 8.1），发现者为本文件作者。CVE 已申请，正在等待 GitHub 分配。 ## 为什么你应该关注 大多数命令注入漏洞需要攻击者已经能触达你的 HTTP API。而这个漏洞只需要一个手机号。 Gammu SMSD 位于调制解调器或 GSM 上网卡的接收端。医院用它做值班寻呼，监控系统用它发送短信告警，不少小店铺把它当作 2FA 方案的廉价半边。一个非常常见的配置是：将来消息以文件形式落盘（Files 后端），并在消息到达时执行一个脚本（RunOnReceive），用于转发、记录或触发后续动作。 这个脚本的输入来自蜂窝网络的外部世界，发送者无需向任何系统认证。而且在很多网络上，发送者ID是一串任意字母数字串，而不是电话号码——这正是银行发短信时显示为 "HSBC" 而不是一堆数字的原因。字母数字发送者ID是攻击者完全可控的，并且可以携带 shell 视为语法的字符。 这就是整个漏洞的核心：一条短信里的值，最终到达了 `/bin/sh`。 ## 漏洞根源 Gammu SMSD 的 Files 后端将每条收到的消息写入文件，文件名包含发送者ID。为保证文件名合法，程序先将发送者ID送入一个转义函数。但问题在于：这个转义只考虑了文件系统的合法性，而没有考虑 shell 语义。 当 RunOnReceive 启用时，Gammu 会把处理后的发送者ID直接追加到 `/bin/sh -c` 命令行中。文件名层面的转义（如过滤路径分隔符）并不能阻止 shell 解释 `$()`、反引号、分号、管道符等元字符。 攻击者只需发送一条发送者ID形如 `$(恶意命令)` 或包含其他 shell 元字符序列的短信，即可在目标机器上以 `gammu-smsd` 用户身份执行任意代码。 ## 攻击场景 1. 运维在短信网关上启用 Files 后端，并开启 RunOnReceive 调用某个处理脚本。 2. 攻击者用手机（或任意能发短信的终端）向该网关发送一条短信，发送者ID设置为精心构造的 shell 注入负载。 3. Gammu 将消息落盘时，转义后的发送者ID被拼进 `/bin/sh -c` 命令。 4. 攻击者构造的 shell 命令随脚本执行，以 gammu-smsd 用户权限在服务器上运行。 整个过程不需要知道目标机器的 IP、不需要任何账号密码、不需要发起网络连接——只需要一个能发短信的手机号。 ## 影响范围 - **攻击路径**：蜂窝网络短信（SMS） - **认证要求**：无 - **利用复杂度**：低 - **权限影响**：以 gammu-smsd 用户身份执行任意命令 - **CVSS 评分**：8.1（高危） ## 修复与缓解建议 1. **立即升级**到 Gammu 1.43.3 或更高版本，官方已修复该问题。 2. 若暂时无法升级，可采取以下缓解措施： - 核查短信网关是否接受字母数字发送者ID；若仅接受纯数字号码，则暴露面会显著降低。 - 审查 RunOnReceive 钩子的调用方式，对传入参数在脚本内部再做一次独立的 shell 转义。 - 以最小权限运行 `gammu-smsd`，限制系统访问范围，降低被攻破后的损害。 - 在短信入口处对发送者ID做白名单校验，拒绝包含 `$`、反引号、`;`、`|` 等危险字符的请求。 ## 时间线 - **2026年7月25日**：GitHub 安全公告 GHSA-9vjj-v46c-c5qf 发布，CVSS 8.1。 - **修复版本**：Gammu 1.43.3。 - **CVE**：已申请，等待 GitHub 分配编号。