Follow Us on WhatsApp | Telegram | Google News

regreSSHion - Critical Remote Code Execution Vulnerability Discovered in OpenSSH

Table of Contents

regreSSHion: RCE Vulnerability in OpenSSH Server

Security researchers at Qualys have uncovered a severe vulnerability in OpenSSH, one of the most widely used secure communication protocols on the internet.

The vulnerability, dubbed "regreSSHion" and assigned the identifier CVE-2024-6387, allows for remote code execution (RCE) on OpenSSH servers running on glibc-based Linux systems.

Qualys in its security advisory, reveals that the vulnerability is a regression of a previously patched issue (CVE-2006-5051) and affects OpenSSH versions from 8.5p1 to versions prior to 9.8p1. This regression was inadvertently introduced in October 2020 with OpenSSH 8.5p1, highlighting the complexity of maintaining security in long-standing software projects.

The cause of the vulnerability is a signal handler race condition in OpenSSH's server (sshd). The issue arises when a client fails to authenticate within the LoginGraceTime period, which is set to 120 seconds by default.

In such cases, sshd's SIGALRM handler is called asynchronously, but this handler invokes functions that are not async-signal-safe, such as syslog().

The vulnerability is particularly concerning as it affects sshd in its default configuration and can be exploited remotely by unauthenticated attackers.

On glibc-based Linux systems, where syslog() calls async-signal-unsafe functions like malloc() and free(), the vulnerability can lead to remote code execution with root privileges. This is because it affects sshd's privileged code, which runs with full system access and is not confined by sandboxing mechanisms.

Qualys researchers demonstrated the exploitability of this vulnerability on multiple Linux distributions, including older versions of Debian and Ubuntu, as well as the current Debian stable release (version 12.5.0). Their proof-of-concept exploits showcase the ability to achieve remote root access on these systems, with varying degrees of difficulty and time requirements.

The advisory provides a detailed technical breakdown of the vulnerability and the exploitation techniques used. It describes how the researchers leveraged memory corruption, heap manipulation, and carefully timed packet transmissions to exploit the race condition.

In a separate blog post, Bharat Jogi, Senior Director, Threat Research Unit, Qualys wrote-

"Based on searches using Censys and Shodan, we have identified over 14 million potentially vulnerable OpenSSH server instances exposed to the Internet." "Anonymized data from Qualys CSAM 3.0 with External Attack Surface Management data reveals that approximately 700,000 external internet-facing instances are vulnerable. "

One of the most alarming aspects of this vulnerability is its potential impact on a wide range of Linux-based servers. While OpenBSD, the original platform for OpenSSH, is not vulnerable due to its use of a more secure syslog_r() function, many other Unix-like operating systems could be affected.

As soon as the details of the vulnerability were disclosed PoC exploit code for CVE-2024-6387 emerged on GitHub. The good news is that a fix for this vulnerability has already been developed and committed to the OpenSSH codebase.


On June 6, 2024, the OpenSSH team addressed the issue with a commit that moves the async-signal-unsafe code from sshd's SIGALRM handler to sshd's listener process, where it can be handled synchronously.

For systems that cannot immediately update to the patched version of OpenSSH, the Qualys advisory suggests alternative mitigation strategies. These include modifying the sshsigdie() function to remove or comment out the async-signal-unsafe code, or setting LoginGraceTime to 0 in the sshd configuration file.

While the latter option may introduce a potential denial of service risk, it effectively mitigates the remote code execution threat.

It is strongly recommended all system administrators worldwide to assess their systems for potential exposure and apply the necessary patches or mitigations as soon as possible.

Read Also
Post a Comment