OpenSSH flaw resurfaces, exposing 14 million servers to RCE

OpenSSH, a pillar of secure software globally, has encountered a rare vulnerability, CVE-2024-6387, within its security framework. This flaw affects 14 million OpenSSH server instances. This flaw is a signal handler race condition that could potentially allow unauthenticated remote code execution on certain systems, posing a significant risk.

This vulnerability is a regression of a two-decade-old flaw, CVE-2006-5051, first identified in 2006. In cybersecurity, a regression occurs when a previous flaw resurfaces due to software changes or updates.

The issue centers on OpenSSH’s server component, .sshd. If a client fails to authenticate within the default LoginGraceTime of 120 seconds (600 seconds in the older versions), sshd’s SIGALRM handler is triggered. This signal handler, however, invokes functions that are not async-signal-safe, such as syslog().

This vulnerability, affecting sshd’s default configuration, traces back to an oversight in a commit from October 2020 (OpenSSH 8.5p1), which inadvertently removed a critical safeguard (#ifdef DO_LOG_SAFE_IN_SIGHAND) from the sigdie() function.

This 2006 vulnerability allowed remote attackers to crash the server and execute arbitrary code. Although a patch was introduced to mitigate this risk, removing the safeguard in 2020 reintroduced this flaw in versions 8.5p1 through 9.8p1.

Here’s a list of the affected OpenSSH versions:

• OpenSSH < 4:4p1: Vulnerable if not patched against CVE-2006-5051 or CVE-2008-4109.
• OpenSSH 4.4p1 ≤ OpenSSH < 8.5p1: Not vulnerable due to async-signal-safe safeguard.
• OpenSSH 8.5p1 ≤ OpenSSH < 9.8p1: Vulnerable again due to the accidental removal of safeguard.

“This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an authenticated remote code execution as root, because it affects sshd’s privileged code, which is not sandboxed and runs with full privileges,” researchers note.

Researchers discovered that OpenBSD systems are not vulnerable, thanks to their use of syslog_r(), and async-signal-safe version of syslog().

Attackers can exploit this vulnerability to execute malicious code to take over the system completely. They can then use the system to install malware, manipulate data, and deploy backdoors for long-term and persistent access.

Furthermore, this flaw could also result in establishing a presence in the network system and using it to exploit other vulnerable systems, thereby expanding the reach within an organisation.

Cybercriminals can also gain root access, which enables them to bypass traditional security measures such as firewalls, logging mechanisms, and other detection software.

Once hackers gain access to the system, they can access all of the data, including sensitive and proprietary information, which can result in significant data leakage.

Researchers have found that exploiting this vulnerability isn’t easy, and threat actors will have to try multiple times to cause memory corruption, which necessitates bypassing Address Space Layout Randomization (ASLR). They also note that deep learning can increase the exploitation rate significantly.

For instance, to exploit OpenSSH_3.4p1, around 10,000 attempts are required, averaging 1 week to achieve remote root shell access. In OpenSSH_4.2p1, the hackers will need around 10,000 attempts, averaging 1-2 days for remote root shell access. Finally, in OpenSSH_9.2p1, the task can be completed in 6-8 hours.

Researchers have reluctant system administrators to review and update their OpenSSH configurations, ensuring they are not using vulnerable versions to mitigate the flaw.

In the News: Mercku’s HelpDesk portal compromised; sends MetaMask phishing emails