openssh漏洞

2024年7月初，OpenSSH项目组悄悄推了一个安全公告。CVE-2024-6387，代号"regreSSHion"——名字起得挺唬人，但真正让人后背发凉的是它的攻击方式：在默认配置的OpenSSH服务器上，攻击者不需要任何凭证，就能远程触发远程代码执行。全球大约有1400万台暴露在公网上的SSH服务器受影响，这个数字来自Qualys的扫描数据。

漏洞本身出在信号处理机制上。OpenSSH的sshd进程里，SIGALRM信号的处理函数调用了非异步信号安全的函数，比如syslog()。glibc环境下，这类调用可能引发堆内存竞争条件。攻击者反复发起连接、在认证超时窗口内精确触发信号，就能把内存踩成自己想要的样子。Qualys团队花了将近一年时间做概念验证，最终在32位Linux上把成功率刷到了大约一万次尝试成功一次。看着不高？但SSH服务通常不会因为你连错一万次就封IP。

这事有意思的地方在于，它其实是个"回归漏洞"。2006年OpenSSH修过一个几乎一模一样的bug，CVE-2006-5051。后来代码重构，那个补丁被意外移除了。所以叫regreSSHion——regression + SSH + onion，一层层剥开全是老问题。开源项目的代码审查有时候就是这么回事，你以为修过的坑，换个马甲又回来了。

影响范围具体到版本：OpenSSH 8.5p1到9.8p1之间的版本，在基于glibc的Linux系统上默认配置就中招。BSD系统因为信号处理机制不同，基本免疫。OpenBSD那帮开发者自己用的就是BSD，所以这个漏洞在他们眼皮底下活了三年才被外人发现。挺讽刺的，但也说明了一件事——平台差异带来的盲区，再老练的团队也躲不过。

修复方案倒不复杂。OpenSSH 9.8p1把信号处理逻辑整个重写了，用poll()替代了部分异步信号逻辑。临时缓解手段也有：把LoginGraceTime设成0，但代价是连接不再有认证超时限制，等于拿可用性换安全。另一个思路是用iptables限制连接频率，不过大规模环境下配置起来很烦。

我自己的判断是，这个漏洞的严重性被稍微高估了一点。远程RCE听起来吓人，但利用条件苛刻——需要精确的时间窗口、特定的glibc版本、持续高频的连接尝试。实际野外利用的门槛不低。可它暴露的问题比漏洞本身更值得琢磨：一个被修复过的安全缺陷，在代码演进中悄悄复活，而全球一半以上的SSH服务跑在默认配置上，没人会去改。

OpenSSH 9.8p1发布后，各大发行版跟进得还算快。Debian、Ubuntu、RHEL都出了补丁。但那些嵌入式设备、老旧的CI/CD容器、没人维护的跳板机呢？它们可能永远停在8.9p1或者9.3p1。扫描一下Shodan，你会发现大量SSH banner还挂着老版本号。漏洞修复从来不只是技术问题。

Qualys在报告末尾提了一句：他们用了一个叫"时序侧信道"的技巧来稳定触发竞争条件。这手法不算新，但用在SSH上还是头一回。安全研究有时候就像在黑暗里摸开关，你知道墙上有，但得试很多次才能碰到。