OpenSSH vulnerability regreSSHion puts millions of servers at risk

Researchers have uncovered a serious remote code execution vulnerability in the Open Secure Shell (OpenSSH) server that could let unauthenticated attackers obtain a root shell on servers and take them over. Through internet scanning services like Shodan and Censys, Qualys researchers identified over 14 million potentially vulnerable OpenSSH instances that were exposed to the internet.

The flaw, tracked as CVE-2024-6387, has been dubbed regreSSHion because it is a regression of an older flaw — CVE-2006-5051 — patched in the popular software 18 years ago.

“A regression in this context means that a flaw, once fixed, has reappeared in a subsequent software release, typically due to changes or updates that inadvertently reintroduce the issue,” said Qualys researchers who discovered the vulnerability. “This incident highlights the crucial role of thorough regression testing to prevent the reintroduction of known vulnerabilities into the environment. This regression was introduced in October 2020 (OpenSSH 8.5p1).”

OpenSSH (sshd) is the most widely used implementation of the SSH protocol which is used for secure communications and remote access on Linux and BSD systems. It is deployed on countless computers on internal networks and on the internet.

The vulnerable versions include those earlier than 4.4p1 if they are missing patches for the older flaws CVE-2006-5051 and CVE-2008-4109, and those after 8.5p1 when the flaw was reintroduced and up to version 9.8p1 released on 1 July when the flaw was repatched.

A race condition in the OpenSSH signal handler

The flaw is caused by sshd’s SIGALRM handler calling various sensitive functions such as syslog() in an asynchronous way when an attempted connection fails to pass authentication within a grace period known as LoginGraceTime.

The issue is that an attacker opening multiple connections and then not providing authentication credentials will be able to trigger the OpenSSH signal handler in an asynchronous way, but the functions called by the handler are not safe to be called asynchronously and could leave the process’ memory heap in an inconsistent state.

When it was first reported in 2006, this was described as a race condition that could lead to denial-of-service (process crash) with the potential for arbitrary code execution, although the latter was never proved because doing so requires winning a race condition by the attacker — meaning it takes many attempts to succeed.

When they found that the flaw was reactivated as a result of accidental removal of a critical component in a function that made OpenSSH safe against this issue, the Qualys researchers set out to prove that remote code execution is possible despite the race condition hurdle. In fact, they had an even harder job ahead of them because since 2006 memory security technologies such as Address Space Layout Randomization (ASLR) were introduced in Linux and other operating systems to make exploitation harder.

“From a theoretical point of view, we must find a useful code path that, if interrupted at the right time by SIGALRM, leaves sshd in an inconsistent state, and we must then exploit this inconsistent state inside the SIGALRM handler,” the researchers wrote in their technical advisory. “From a practical point of view, we must find a way to reach this useful code path in sshd and maximize our chances of interrupting it at the right time. From a timing point of view, we must find a way to further increase our chances of interrupting this useful code path at the right time, remotely.”

The researchers demonstrated the exploit against Linux systems that use the glibc C library and on 32-bit versions because the ASLR is weaker due to the reduced memory space. However, exploitation on 64-bit systems is also possible but potentially more difficult.

Against OpenSSH 9.2p1 from the stable version of Debian Linux i386 the researchers needed around 10,000 tries to win the race condition and exploit the flaw. This means between 3-4 hours with 100 concurrent connections and a default LoginGraceTime of 120 seconds. However, because of ASLR glibc’s address can only be guessed correctly half of the time, the time for achieving remote code execution with a root shell increases to between 6-8 hours.

OpenSSH deployments on OpenBSD are not vulnerable because its signal handler calls syslog_r(), a version of syslog() developed by OpenBSD in 2001 that is safe for asynchronous calls.

How to mitigate OpenSSH regreSSHion vulnerability

Upgrading OpenSSH to a patched version is highly recommended as soon as it becomes available in the package repositories of Linux distributions. If a patched package is not immediately available in a distribution, an alternative mitigation is to set the LoginGraceTime parameter to 0 in the sshd configuration file, according to Red Hat.

Also, the very large number of connections needed to win this race condition could be detected and blocked via network monitoring tools and firewalls. The difficulty to exploit the flaw is also the reason why its severity is rated as 8.1 (important) on the CVSS scale instead of critical.

More by Lucian Constantin:

• Microsoft fixes dangerous zero-click Outlook remote code execution exploit
• Critical PyTorch flaw puts sensitive AI data at risk
• New RansomHub ransomware gang has ties to older Knight group