openssh命令注入漏洞

OpenSSH 又爆了一个命令注入漏洞，令注编号 CVE-2023-51385。入漏攻击者可以构造一个恶意主机名，令注当用户用 git 或 scp 等工具连接时，入漏触发 ProxyCommand 中的令注命令注入，最终在本地执行任意代码。入漏这不是令注理论推演，是入漏实实在在能利用的漏洞，PoC 已经在 GitHub 上公开。令注

问题的入漏根源在 OpenSSH 对主机名的处理上。ssh_config 里有个 ProxyCommand 选项，令注允许用户通过外部命令来建立连接。入漏比如你配置了 ProxyCommand ssh -W %h:%p jumpbox，令注这里的入漏 %h 会被替换成目标主机名。OpenSSH 在替换时没有对主机名做充分过滤，令注如果主机名里包含 shell 元字符——比如反引号、分号、管道符——这些字符会被直接传给 shell 执行。

攻击场景很具体。假设你克隆一个恶意仓库，仓库的 .gitmodules 文件里定义了一个子模块，URL 里嵌入了一个精心构造的主机名。当你执行 git submodule update --init 时，git 会调用 ssh 去连接这个主机。如果 ssh_config 里恰好启用了 ProxyCommand，注入的代码就会在本地跑起来。整个过程你甚至看不到任何异常输出。

这个漏洞的 CVSS 评分是 8.1，高危。受影响版本从 OpenSSH 5.5 一直到 9.5，跨度超过十年。OpenSSH 9.6 修复了这个问题，做法是在 ProxyCommand 替换 %h 时，对主机名中的特殊字符进行转义。但问题在于，很多发行版还没跟进更新，尤其是那些长期支持版本。

我注意到一个细节：这个漏洞的利用条件并不苛刻。你不需要 root 权限，不需要目标主机在线，甚至不需要用户手动输入任何东西。只要用户克隆了恶意仓库，并且本地 ssh_config 里配置了 ProxyCommand，攻击就能成立。ProxyCommand 在企业环境里用得很多——跳板机、堡垒机、内网穿透，都依赖它。这意味着受影响的用户群体比想象中大得多。

有人可能会说，我不配 ProxyCommand 不就没事了。但现实是，很多自动化工具、CI 流水线、开发框架会默认生成包含 ProxyCommand 的 ssh_config。你甚至不知道自己什么时候被配上了。检查方法很简单：grep -r ProxyCommand ~/.ssh/ /etc/ssh/，看看有没有命中。

修复方案有两个层面。第一，升级 OpenSSH 到 9.6 或更高版本。第二，如果暂时不能升级，可以在 ssh_config 里避免使用 %h，改用 %n 或者直接写死主机名。但这些都是权宜之计。根本问题在于，OpenSSH 把主机名当成了可信输入，而主机名在实际场景中来自不可信来源——git 仓库、URL、配置文件，都可能被攻击者控制。

我翻了一下 OpenSSH 的提交记录，修复补丁其实很小，就几行代码。但就是这几行代码，堵住了一个存在十年的注入通道。这让我想起一句话：安全漏洞往往不是复杂逻辑错误，而是对输入边界的长期忽视。主机名看起来人畜无害，但它可以包含任何字符，包括那些能让 shell 兴奋的字符。

最后说一个实际观察。这个漏洞公开后，很多人的第一反应是“我又不用 ProxyCommand”。但你去翻翻自己的 ~/.ssh/config，或者看看公司发的开发环境配置，大概率能找到几行 ProxyCommand。攻击者不需要你主动使用它，只需要你克隆一个仓库。这就是供应链攻击的可怕之处——你信任的是 git，但 git 信任的是 ssh，而 ssh 信任的是主机名。信任链上任何一环被污染，整个链条就断了。