Researchers discovered a pre-authenticated RCE vulnerability in OpenSSH server, named regreSSHion (CVE-2024-6387).

If exploited successfully, the vulnerability allows attackers root access to a Linux machine, without needing to know any credentials. The only technical limitation, outside of a considerably complicated exploit, is that the machine is glibc-based, which is a fairly standard configuration.

Technical details

Linux Signal Handlers allow programmers to execute a specific logic upon receiving a signal.

These signal handlers, by nature, could be executed asynchronously - meaning it could interrupt a function’s logic while it is still executing.

This creates a requirement that the signal handlers must only run “signal safe” functions that can not alter the state that the rest of the program relies on. 

The OpenSSH vulnerability was exactly that: Namely the `syslog()` function is not signal-safe, as under some circumstances, it can call `malloc()` and `free()` - and in a situation where a signal handler calls `malloc()` or `free()` during a heap-related operation, it could lead to a heap memory corruption. Since signals are local to the machine, an exploit needs to use the exact timing to take advantage of this vulnerability. While exploitation is complicated, it seems possible based on initial research.

Essentially, this is a race-condition vulnerability (signal-oriented), that leads to a heap memory corruption.

The original publication goes into great depth of technical details, so we will not repeat those here.

Likelihood of exploitation

Although there already is a Proof-of-Concept exploit for the vulnerability, it shows that exploitation is possible in a lab setting. It is a statistical exploit in nature: it takes a significant amount of attempts in order to win the race condition and successfully execute arbitrary code.

Luckily, there are quite a few obstacles that attackers would need to overcome. This together puts the risk of “mass exploitation” to be lower, as currently the best known exploit takes several (4+ hours) to run, even in the best-case scenario. It also creates a window of possibility for more advanced detections against the vulnerability.

The complexity of the exploit does not mean that it is not possible. It definitely is possible and opens up a lot of opportunities for attackers to breach into organizations, and our recommendation is to patch against the vulnerability as soon as possible.

What is the fix?

The latest OpenSSH version 9,8 that was just released today contains a fix for this vulnerability, and it’s recommended to upgrade your affected deployment wherever possible, focusing on publicly exposed hosts first. You should also try to limit access to SSH servers and monitor for suspicious network activity.

How Dazz is helping customers

Before detection signatures were even rolled out, we started working with customers to identify resources running OpenSSH that were likely to be impacted. With detection signatures added, it then became easy to:

1. Assess impact: identify all instances of CVE-2024-6387 found across multiple scanners and detection tools
2. Prioritize: focus on instances of CVE-2024-6387 known to affect internet-facing hosts
3. Respond: automate ticket creation and monitor the patch status: Dazz can automatically create tickets for owners of infrastructure affected by CVE-2024-6387 and track ticket status as an initial method for reporting the remediation process. In addition, Dazz can compare ticket status with the latest scans for validation that the vulnerability is no longer present on systems.

If you have questions about the regreSSHion vulnerability (CVE-2024-6387), please don’t hesitate to reach out to our experts.