CVE-2024-6387

July 1, 2024

Minutes Read

Remote Code Execution in OpenSSH’s Server (CVE-2024-6387) – regreSSHion

Advisory

Security Advisory

July 1, 2024

Minutes Read

Remote Code Execution in OpenSSH’s Server (CVE-2024-6387) – regreSSHion

This is some text inside of a div block.

Minutes Read

Kudelski Security Team

Find out more

table of contents

Share on

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Updates made on July 3

Summary

A critical vulnerability (CVE-2024-6387) named regreSSHion has been discovered in OpenSSH’s server (sshd), which allows for remote code execution (RCE) due to a signal handler race condition triggered when a client fails to authenticate within a specified time frame (LoginGraceTime). This vulnerability was inadvertently reintroduced in October 2020 and affects OpenSSH versions from 8.5p1 up to 9.7p1 on glibc-based Linux systems. It can be exploited remotely by unauthenticated attackers, potentially allowing them to execute arbitrary code as root.

Affected Systems and/or Application

Vulnerable

OpenSSH < 4.4p1 if not backport-patched against CVE-2006-5051 or CVE-2008-4109.
8.5p1 <= OpenSSH < 9.8p1 due to the accidental removal of a critical safety check in the signal handler.

Not Vulnerable:

4.4p1 <= OpenSSH < 8.4p1, protected by the “#ifdef DO_LOG_SAFE_IN_SIGHAND” directive.
OpenBSD versions, which use syslog_r(), an async-signal-safe version of syslog().

Technical Details / Attack Overview

The vulnerability arises when sshd’s SIGALRM handler is called asynchronously if a client does not authenticate within the LoginGraceTime period. The handler calls syslog(), which is not async-signal-safe, leading to a race condition. This can be exploited to achieve remote code execution in sshd’s privileged code.

The exploit involves three main versions of OpenSSH on different Debian and Ubuntu systems. Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR enabled. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept.

SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, 2005)
- Theory: Targeted free() calls during sshd’s public-key parsing code, causing heap corruption.
- Practice: Achieving remote root shell required ~10,000 tries, it takes ~1 week on average to obtain a remote root shell.
SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 (Ubuntu 6.06.1, 2006)
- Theory: Focused on pam_start() in SIGALRM handler to make PAM’s structure inconsistent and then exploit this state during a call to pam_end().
- Practice: Similar number of attempts (~10,000), it takes ~1-2 days on average to obtain a remote root shell.
SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2 (Debian 12.5.0, 2024)
- Theory: Exploited malloc() calls in syslog() within SIGALRM handler.
- Practice: Similar number of attempts (~10,000), it takes ~6-8 hours in average to obtain a remote root shell.

Temporary Workarounds

SSHD Code

You can directly modify the code to add to the following function sshsigdie() a C preprocessor directive statement to avoid calling unsafe functions. But keep in mind that those workarounds could have some side effect and this has not been tested, as such the CFC recommends instead to update the ssh version.

SSH Configuration Hardening

Adjust the following settings in `sshd_config` to reduce the effectiveness of potential attackers:

LoginGraceTime

Set `LoginGraceTime` to 0: This prevents the vulnerability by eliminating the authentication timeout period.
Caution: This setting can potentially tie up system resources, as it removes the timeout for authentication attempts.

MaxStartups

Set `MaxStartups` to a small number: Lowering this limit restricts the number of unauthenticated connections.
Caution: Setting this value too low may block legitimate users, especially if an attacker is aggressive or if there is a high user count on the host.

PerSourceMaxStartups

Set `PerSourceMaxStartups` to a small number: This limits concurrent unauthenticated connections from a single source IP.
Caution: Setting this value too low may block legitimate users, especially if an attacker is aggressive or if there is a high user count on the host.

By implementing these configurations, you can enhance the security of your SSH server and mitigate the risk of exploitation, but this will expose sshd to a denial of service by exhausting all connections, but it will eliminate the risk of remote code execution.

Recommendations

Addressing the regreSSHion vulnerability in OpenSSH, which allows remote code execution on Linux systems, requires a strategic and multi-layered security approach. Here are a few steps and recommendations to protect against this critical issue:

Patch Management: Immediately apply available OpenSSH patches and prioritize regular updates.
Enhanced Access Control: Restrict SSH access using network-based controls to reduce attack surface.
Network Segmentation and Intrusion Detection: Segment networks to prevent unauthorized access and lateral movement within critical systems, and deploy intrusion detection systems to monitor and alert on suspicious activities indicative of exploitation attempts.

What is the CFC doing ?

Kudelski Security has not observed or received indicators of active exploitation of these flaws at the time of writing. The CFC will continue to monitor the situation and send an advisory update if needed. Clients with vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a plugin is available from the scan provider.