OpenSSH: Another RegreSSHion-like vulnerability discovered

A vulnerability in OpenSSH that became known last week allowed attackers to carry out a brute force attack, at the end of which a root shell was waiting. Based on this vulnerability, dubbed "RegreSSHion" (CVE-2024-6387), an IT researcher continued his search and found what he was looking for: Another similar vulnerability lies dormant in the code of secure access software, particularly Red Hat Enterprise Linux.

The description of the new vulnerability is as follows: A race condition can occur in an OpenSSH signal handler if a client does not authenticate within the "LoginGraceTime" - 120 seconds by default, 600 seconds in older OpenSSH versions. In this case, the SIGALRM handler of the sshd is called asynchronously. This in turn calls various functions that are not "async-signal-safe", such as syslog(). This leads to a signal handler race condition in the cleanup_exit() function. This leads to the same vulnerability in the unprivileged child process of the sshd server as CVE-2024-6387. In the worst case, attackers can execute code from the network, in the user context of the OpenSSH server, with low privileges (CVE-2024-6409, CVSS 7.0, risk"high").

Only a few Linux distributions affected

A very clear restriction follows: This vulnerability only affects the sshd server, which is delivered with Red Hat Enterprise Linux 9. The upstream versions are therefore not affected by the error. The vulnerability report or the OSS security mailing list is somewhat more detailed. There it is explained that OpenSSH 8.7 and 8.8 call the cleanup_exit() function from the grace_alarm_handler(), whereby cleanup_exit() was never intended to be called from a signal handler, as it is not async-safe.

However, downstream patches occasionally lead to such async-unsafe function calls. The Red Hat OpenSSH package contains the openssh-7.6p1-audit.patch, which introduces this faulty behavior. The patch can be found in particular in RHEL 9 and corresponding rebuilds or downstream distributions in which OpenSSH is based on 8.7p1. But Fedora is also affected, in packages based on OpenSSH 8.7p1 and 8.8p1. However, this is limited to Fedora 36 and 37, and some updates for Fedora 35 to 37 may have brought this with them. However, these have reached End-of-Life (EoL) and Fedora 38 and newer have switched to newer upstream OpenSSH.

The main difference to the "RegreSSHion" gap is that the race condition is triggered in a permission-separated child process, which runs with lower permissions compared to the parent process. The direct effects are therefore lower. However, the exploitability in certain scenarios could be interesting for attackers. Temporary countermeasures such as setting the LoginGraceTime to 0 seconds therefore help against both vulnerabilities. The "-e" countermeasure, on the other hand, helps completely against CVE-2024-6387, but only to a limited extent against CVE-2024-6409. However, an exploit against the new vulnerability has not yet been attempted and its exploitability has therefore not yet been proven. However, as with the RegreSSHion vulnerability, the IT security researchers at Qualys have confirmed and analyzed the vulnerability.

Admins should install updated OpenSSH packages for RHEL and modified Linux distributions. Or at least implement the proposed countermeasure by lowering the LoginGraceTime until then.

Read also

RegreSSHion: Security gap in OpenSSH gives patient attackers root rights

---

regreSSHion gap: New SSH feature offers protection, proof of concept is none

The "RegreSSHion" vulnerability became known at the beginning of last week. It allows attackers to carry out brute force attacks that result in access with root rights in around eight hours.

(dmk)