本人小白菜，又小白又菜。此处写出的内容仅作为抛砖引玉，望各位大佬补充。
简介
在 OpenSSH 中发现了一个远程代码执行（RCE）漏洞，原因是异步调用 sshd 的 SIGALRM 处理程序的代码不是异步信号安全的。这个漏洞存在于 OpenSSH < 4.4p1 或 8.5p1 <= OpenSSH < 9.8p1 的版本中，并在基于 glibc 的 Linux 发行版中可被利用。旧版本OpenSSH的漏洞已经于CVE-2003-0693 和 CVE-2002-0640 后修复。[1]其较新版本的漏洞与在2023年曾报告的一个死锁问题相关。[2][3]
报告内容如下[1]:
We discovered a vulnerability (a signal handler race condition) in OpenSSH's server (sshd): if a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd's SIGALRM handler is called asynchronously, but this signal handler calls various functions that are not async-signal-safe (for example, syslog()). This race condition affects sshd in its default configuration.
·----------------------------·
·-- (Translated by OpenAI) --·
·----------------------------·
我们在OpenSSH的服务器（sshd）中发现了一个漏洞（信号处理器竞态条件）：如果客户端在LoginGraceTime秒内（默认为120，旧版OpenSSH为600）未进行身份验证，则异步调用sshd的SIGALRM处理程序，但此信号处理程序调用了各种非异步信号安全的函数（例如syslog()）。这个竞态条件影响到了sshd的默认配置。
报告称在32位（i386）操作系统下，新版本OpenSSH 被攻击并获得根用户Shell平均需要大约 6-8 小时，由于64位系统的 ASLR 更强，因此漏洞利用难度更大。但漏洞报告者同时指出，该漏洞利用的各个方面均有优化空间。[1]
建议操作
现在各发行版均针对此问题发布 / 正在发布安全更新，一般包含在 security 源中。建议用户使用官方安全更新源，并及时更新以避免因该漏洞造成损失。第三方软件源可能由于同步原因更新缓慢。[4]
同时由于 CentOS 7 的服务周期于昨日终止[5]，虽然本次我们建议现有 CentOS 7 用户迁移至其他环境类似的操作系统，如 OpenSUSE, Rocky 等。
部分系统修复后的版本号如下所示，仅供参考：
Debian [6] （u3即包含patch）
bullseye（Debian 11 不受影响）
openssh (1:9.2p1-2+deb12u3) bookworm-security; urgency=high
openssh (1:9.7p1-7) unstable; urgency=critical
Ubuntu [7] (根据说明，24.04 不被影响，参见 [1] - Side note, [13])
openssh (1:9.3p1-1ubuntu3.6) mantic-security; urgency=medium
openssh (1:9.6p1-3ubuntu13.3) noble-security; urgency=medium
openssh (1:8.9p1-3ubuntu0.10) jammy-security; urgency=medium
openssh (1:9.6p1-3ubuntu15) oracular; urgency=medium
Arch Linux [8]
openssh-9.8p1-1-x86_64
Alpine Linux [9]
尚未发布更新，存在构建问题。[9]
OpenSUSE [10]
尚未发布更新，已进入Staging Workflow。 [10]
Fedora [11]
尚未发布更新。[11]
RHEL , CentOS [12]
7-8不受影响，9尚未发布更新。[12]
临时解决方案[1]：
在 RHEL 等仍未发布补丁的系统，或原有系统无法升级的情况下，可以在 sshd_config 文件中配置LoginGraceTime 0
后，重新启动 sshd 服务systemctl restart sshd ( 部分系统需要 sudo systemctl restart ssh)。请注意这使得sshd容易受到拒绝服务攻击（耗尽所有MaxStartups连接，使得无法访问服务器），但它使其免受本问题的远程代码执行的威胁。如果说将LoginGraceTime 配置为0，可能导致由于网络延迟等原因无法通过ssh进行访问。
参考链接
[1] https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt
[2] https://bugzilla.mindrot.org/show_bug.cgi?id=3598
[3] https://bugzilla.mindrot.org/show_bug.cgi?id=3690
[4] https://www.debian.org/mirror/ftpmirror#:~:text=We%20recommend%20debian%2Dsecurity%20not%20be%20mirrored.
[5] https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/
[6] https://security-tracker.debian.org/tracker/CVE-2024-6387
[7] https://launchpad.net/ubuntu/+source/openssh/+changelog
[8] https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/commit/af3308ddc8fcc6752f809fd20e0ea287d15734ea
[9] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68482
[10] https://build.opensuse.org/request/show/1184302
[11] https://packages.fedoraproject.org/pkgs/openssh/openssh-server/
[12] https://access.redhat.com/security/cve/cve-2024-6387
[13]https://git.launchpad.net/ubuntu/+source/openssh/tree/debian/patches/systemd-socket-activation.patch
浅谈
到底发生了什么
当客户端在 LoginGraceTime 时间内没有完成认证，sshd 会触发一个 SIGALRM 信号。SIGALRM 调用到了 sshsigdie 而sshsigdie 调用了 syslog 记录日志，syslog不是异步信号安全的函数，因为它内部调用了 malloc，glibc的 malloc是内存不安全的。因此只要 SIGALRM 触发时发送恶意的 key 信息，就可能造成内存不一致。利用特定的堆内存分配特性，攻击者可以通过堆写入恶意数据，最终获得对内存的控制权。
漏洞危害性
评分较高，属于OpenSSH多年以来再一次出现RCE，结果还是跌到了当年那个坑上。所以不属于很难修复的，但是如果不修复ssh在系统中的地位还是比较危险的
被利用难度
不好评价，但是64位为主的年代由于 ASLR 保护了内存地址，因此相对来说要比 32 位系统利用困难。但是作者也说了存在优化利用方法的可能，并且可能64位系统希望在一周之内利用到。但是存在一点是，该攻击和时间存在较强关系，因此在文中提到
on a mostly stable network link (~10ms packet jitter)。
不需要过度关心版本号
更新后检查本系统的 OpenSSH 版本号，不需要保证在无漏洞范围内，而是保证在特定的patch过的小版本号下。理论来说这个漏洞很容易patch掉，因此各大发行版都选择patch现有版本而不是直接用最新版本。
Arch, NixOS, Gentoo除外
举例子，还没有合并的 OpenSUSE 对该漏洞的修复方法是增加 fix-CVE-2024-6387.patch 针对 sshsigdie的log直接处理。
不更新，改配置文件的临时解决方案做了什么
如上文所属，这个漏洞和时间以及时序相关，是因为特定状态下被分配了内存地址因此被利用。 LoginGraceTime 的目的主要是一个认证窗口，在这个窗口下被攻击才有可能。而 MaxStartups对于未认证链接的限制。
如同原报告文件中提到
it takes ~10,000 tries on average to win the race condition; i.e., with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime), it takes ~3-4 hours on average to win the race condition, and ~6-8 hours to obtain a remote root shell(because of ASLR).
其难度和窗口相关，10000 / 100 * 120 = 12000s = 3.33*h 所以得出的结果是 最低3-4小时。
所以说 如果把 LoginGraceTime 尽可能减小并将 MaxStartups 尽可能放大就可以增加利用该漏洞的难度。因此极限来说，无法利用也就是 LoginGraceTime 设置为0 ， 但是这样会造成无法完成认证的问题（尤其是在复杂的网络条件下，时间窗口过短，特别是针对密码认证）。而这时 MaxStartups 并不存在作用，因此虽然无法利用时序问题来进行攻击，但是因为所有连接在打开后立即断开，因此存在被DDoS攻击的可能。
实际建议
用好防火墙，用好 fail2ban，把尝试直接挡到防火墙外面！
雷达卡
发表于 2024-7-2 02:43:31
提升卡
置顶卡
变色卡
顶贴箭
发表于 2024-7-2 02:46:42
