vulnerabilities
A vulnerability has been discovered in OpenSSH, a popular set of tools for remote management of *nix systems. The bug allows an unauthenticated attacker to execute arbitrary code on the affected system and gain root privileges. The vulnerability was named regreSSHion, and assigned the ID CVE-2024-6387. Given that sshd, the OpenSSH server, is integrated into most operating systems and many IoT devices as well as firewalls, the description of the vulnerability sounds like the beginning of a new epidemic on the scale of WannaCry and Log4Shell. In practice, the situation is somewhat more complex. Widespread exploitation of the vulnerability is unlikely. Nevertheless, all server administrators using OpenSSH must urgently address the vulnerability.
Where OpenSSH is Used
The OpenSSH utility set is almost ubiquitous. It is a popular implementation of the SSH (secure shell) protocol, and is integrated into most Linux distributions, OpenBSD and FreeBSD, macOS, as well as specialized devices like those based on Junos OS. Since many TVs, smart doorbells, baby monitors, network media players, and even robotic vacuum cleaners are based on Linux systems, OpenSSH is often used in them as well. Starting with Windows 10, OpenSSH is also available in Microsoft’s OSs, although it’s an optional component not installed by default. It’s no exaggeration to say that sshd runs on tens of millions of devices.
How to trigger the regreSSHion vulnerability
During an SSH authentication attempt, the user has a time limit to complete the process, with the default setting being 120 seconds. If authentication does not occur, the sshd server asynchronously calls the special “sigalarm” function, which in turn invokes system-level memory management functions. This was done in a manner unsafe for asynchronous execution. Under certain conditions, and with a small probability, this can trigger a race condition, leading to memory boundary violations and arbitrary code execution.
To exploit this vulnerability, an attacker needs to make approximately 10,000 attempts on average, and the target system must be based on Linux versions using the GNU C Library (glibc), such as all Debian variants. Additionally, attackers need to prepare memory structures tailored to the specific version of glibc and Linux. Researchers have reproduced the attack on 32-bit Linux systems but, theoretically, it’s possible to exploit on 64-bit systems as well — albeit with a lower success rate. Address Space Layout Randomization (ASLR) slows down the exploitation process but does not provide complete protection.
Interestingly, this bug was already fixed by the OpenSSH team in 2006, when it was assigned CVE-2006-5051. Therefore, the new bug is a regression — the reappearance of an already known defect due to some changes introduced in the code. This is where the name for the new vulnerability, regreSSHion, comes from.
The likelihood of CVE-2024-6387 being exploited in the wild
The vulnerability was discovered by researchers and responsibly disclosed to the development team. Therefore, immediate exploitation is unlikely. Moreover, the technical complexities described above make mass exploitation impractical. Ten thousand authentication attempts with standard OpenSSH settings would take six to eight hours per server. Additionally, one needs to know which version of Linux the server is running. If the server has any protection against brute force attacks and DDoS, these measures would likely block the attack.
Despite all this, targeted exploitation is quite possible. Patient attackers can conduct reconnaissance and then make low-frequency attempts from different IPs, and sooner or later they might succeed.
How to protect your servers against exploitation
Versions of OpenSSH up to 4.4p1, plus versions from 8.5p1 to 9.7p1 running on glibc-Linux, are vulnerable. OpenBSD-based servers are not affected, so admins of those can breathe easier; however, everyone else should update sshd to version 9.8.
If for some reason immediate updating is not possible, administrators can set the login timeout to zero (LoginGraceTime=0 in sshd_config) as a temporary mitigation. However, developers warn that this makes the SSH server more susceptible to DDoS attacks.
Another possible mitigation is stricter access control for SSH — implemented using firewalls and other network security tools.
Tips