2024年7月，限提OpenSSH 9.8p1发布，升漏修了一个叫CVE-2024-6387的限提漏洞。Qualys的升漏研究员把它命名为"regreSSHion"——这个名字不是随便起的，因为它是限提2020年CVE-2020-15778的回归变种。一个十多年前修过的升漏信号处理问题，换了个马甲又回来了。限提

问题出在sshd的升漏SIGALRM处理器上。OpenSSH的限提认证流程有一个LoginGraceTime超时机制，默认120秒。升漏客户端连上来之后如果没完成认证，限提服务端会触发SIGALRM，升漏在信号处理函数里做一些清理工作。限提这个处理函数调用了syslog()等非异步信号安全的升漏函数。信号处理函数里调用非异步信号安全的限提函数，是C语言编程里非常经典的一类错误——问题是，这段代码在glibc环境下会触发堆内存竞争，攻击者通过精心构造的时序，有可能在sshd的堆上写入任意数据。

利用难度和真实风险

Qualys在实验室环境里跑了大约10000次尝试才成功一次，耗时6到8小时。这个成功率听起来很低。但换个角度：如果目标暴露在公网，攻击者可以同时发起大量连接，把时间窗口压缩到可接受的范围。32位Linux系统上利用相对容易，64位系统上因为地址空间大，难度高不少，但不是不可能。

更麻烦的是sshd以root权限运行。一旦利用成功，攻击者直接拿到root，不需要再做任何提权操作。这和那些需要先登录再提权的漏洞完全不是一个量级。

受影响的版本范围很宽：OpenSSH 8.5p1到9.8p1之间的版本，在特定glibc配置下都存在这个问题。再往前追溯，OpenSSH 4.4p1之前的版本也有类似缺陷，后来被修了，但在8.5p1附近因为一次代码重构又被引入。这种"修了又回来"的情况在底层C代码里其实不罕见，尤其是涉及信号处理和内存管理的交叉地带。

为什么这个漏洞值得关注

OpenSSH几乎是所有Linux服务器的标配入口。它不是一个可选组件，而是基础设施本身。这个漏洞不需要任何认证就能触发，攻击面是sshd的预认证阶段——也就是任何人只要能把TCP包发到22端口，就能尝试利用。

实际扫描数据显示，公网上暴露的OpenSSH实例数量以千万计。虽然大部分发行版在漏洞公开后几天内就推送了补丁，但企业环境里"补丁滞后"是常态。我见过一些内部系统还在跑CentOS 7自带的OpenSSH 7.4，而这类老版本恰好落在受影响区间内。

缓解措施方面，把LoginGraceTime设为0可以绕过这个漏洞——代价是失去超时保护，可能导致连接资源耗尽。另一种做法是用MaxStartups限制并发未认证连接数，降低攻击者反复尝试的窗口。这些都不是根治方案，只是临时降低风险。

个人观察

这个漏洞让我想起一个老问题：C语言里信号处理函数的约束条件，很多开发者其实并不清楚。异步信号安全函数的列表是POSIX明确规定的，但实际编码中，在SIGALRM处理器里调syslog、malloc、free的情况比比皆是。编译器不会报错，运行时大部分时候也不出问题，直到某个特定时序被触发。

OpenSSH的代码质量在开源项目里算高的，代码审查也很严格。但这类漏洞说明，即使是最成熟的C项目，在信号处理和内存管理的交叉区域仍然脆弱。regreSSHion不是第一个，也不会是最后一个。

补丁已经出了，升级到9.8p1或更高版本就行。如果暂时不能升级，检查你的sshd_config，确认LoginGraceTime和MaxStartups的设置。别拖。