The Qualys Threat Research Unit (TRU) uncovered the CVE-2024-6387 vulnerability, also called regreSSHion. This flaw, leveraging a signal handler race condition affecting OpenSSH’s server (sshd) on Linux systems, allows unauthenticated remote code execution (RCE).

Vulnerability Timeline:

The vulnerability originated as CVE-2006-5051 in OpenSSH versions before 4.4, involving a signal handler race condition.

It was initially addressed in OpenSSH 4.4p1 by adding a “#ifdef DO_LOG_SAFE_IN_SIGHAND” check to the sigdie() function, transforming it into a safe _exit(1) call.

However, this fix was incomplete, leading to CVE-2008-4109. In October 2020, OpenSSH 8.5p1 accidentally reintroduced the vulnerability by removing the “#ifdef DO_LOG_SAFE_IN_SIGHAND” check from sigdie() during a revision of the logging infrastructure.

This reintroduction is now identified as CVE-2024-6387. The vulnerability was finally fixed correctly on June 6, 2024, by moving the async-signal-unsafe code from sshd’s SIGALRM handler to sshd’s listener process for synchronous handling

What exactly are “Signals”, “Signal Safety”, and their use:

Signals are a form of inter-process communication in Unix-like operating systems, used to notify a process of an event or to request it to perform a specific action (similar to traffic officers at the intersection).
They are asynchronous notifications sent to processes to handle various scenarios such as termination requests, illegal memory access, or timer expiration.

In sshd, signals are used for management and control purposes. Specifically, the SIGALRM signal is used to implement a timeout mechanism (LoginGraceTime) to prevent hung connections and potential denial-of-service attacks.

When a client does not authenticate within the specified time, SIGALRM is triggered to gracefully terminate the connection. This use of signals allows sshd to maintain responsiveness and security by handling timeouts without the need for complex polling mechanisms or dedicated threads for each connection.

Signal safety refers to functions that can be safely called from within a signal handler without causing undefined behavior or race conditions.
A function is async-signal-safe if it is reentrant or atomic with respect to signals. In the various affected versions of sshd, the SIGALRM handler called functions that were not async-signal-safe, such as syslog(), which internally calls malloc() and free().

This created a race condition where the heap could be left in an inconsistent state if the signal handler interrupted certain memory operations. The failure occurred because sshd’s signal handler performed complex operations that could interfere with the main program’s execution, violating the principle of keeping signal handlers simple and async-signal-safe.

Why should you care?

SSH (Secure Shell) is a widely used protocol that establishes encrypted connections between two hosts over an insecure network. It ensures secure communication by authenticating both sides and encrypting data during transmission. SSH serves multiple purposes, including remote server management, secure file transfers, and private network access.

According to the Shodan search engine, more than 23 million public servers are found running OpenSSH while it is estimated by Qualys that 14 million of them are potentially vulnerable.

Is my organization affected?

To determine if your systems are affected by CVE-2024-6387 (regreSSHion), please evaluate if your organization is exposing its OpenSSH server from Linux-based servers/endpoints to the internet or exposing them inside your organization.
Check the version of the server running and if needed, patch it to the latest version which is currently 9.8p1 (released on July 1, 2024).

Winning the race – Exploiting OpenSSH 9.2p1

The vulnerability relies on a race condition, where an attacker tries to gain unauthorized access during a brief window.
We estimate that by using 100 connections (the Default MaxStartups value) accepted per 120 seconds (the Default LoginGraceTime value), it takes about 3-4 hours on average to win a race condition and thus successfully exploit the RegreSSHion CVE-2024-6387 vulnerability.

Making the race harder – Mitigation steps

While the best approach to handle this vulnerability is simply updating your OpenSSH version to the latest one, at Cynet’s labs we have found a way to make the race harder by implementing the following:

  1. Locate the sshd configuration file:
    • On most Unix-like systems, this is typically /etc/ssh/sshd_config
    • Use sudo or switch to root to edit this file
  2. Open the configuration file in a text editor:
    • sudo nano /etc/ssh/sshd_config
  3. Find or add the LoginGraceTime setting:
    • If it exists, modify it to: LoginGraceTime 0
    • If it doesn’t exist, add this line
  4. Save the changes and exit the text editor
    • In nano, press Ctrl+X, then Y, then Enter
  5. Restart the SSH service to apply the changes:
    • On systemd-based systems: sudo systemctl restart sshd
    • On older init systems: sudo service sshd restart
  6. Verify the changes have been applied:
    • sudo sshd -T | grep ‘logingracetime’
  7. Test SSH access to ensure the service is still functioning correctly

The effect of the changes:

Setting LoginGraceTime to 0 disables the login grace period entirely. This means that sshd will not use a timer to close the connection if authentication isn’t completed within a certain time.

As stated in the advisory, this change prevents the exploitation of the signal handler race condition described in CVE-2024-6387. However, it’s important to note that this also removes the protection against potential denial-of-service attacks that the timeout provides. Administrators should carefully consider this trade-off and monitor their systems for any unusual connection patterns or resource exhaustion.

Cynet multilayer mechanisms

Cynet utilizes a strong, multi-layered detection system to counter targeted attacks, covering both the pre-exploitation and post-exploitation phases.
These capabilities are strengthened by CyOps 24/7 coverage of our customers’ environments.
It’s crucial to stay up to date with patches to address overall security.

Important note:

Cynet, and Cynet360 is not affected by CVE-2024-6389.
Cynet continues to monitor this vulnerability and will update on any developments, dependencies, and measures to be taken to mitigate the threat caused by it.
In addition, our research group is working around the clock to add detection logic and capabilities against this vulnerability.