What Happened?
Security researchers at Qualys have identified a race condition vulnerability in OpenSSH server (sshd) that could result in remote code execution (RCE) with root privileges. This vulnerability is being tracked as CVE-2024-6387 and has been unofficially dubbed, “regreSSHion” by the Qualys team. It was given this name because its presence reveals a patch regression in OpenSSH server as this vulnerability was previously identified and patched in 2006 (OpenSSH 4.4p1) under CVE-2006-5051. After being properly mitigated in 2006, the vulnerability was accidentally reintroduced in October 2020 (OpenSSH 8.5p1). A patch was made available on July 1st 2024 by the OpenSSH team; upgrading to the latest version of OpenSSH server version (9.8p1) mitigates this vulnerability.
How Bad is This?
Remote code execution with root privileges is never a good thing when it rears its ugly head. However, the difficulty of exploitation for this vulnerability and its somewhat limited attack surface reduces the overall criticality. Don’t get me wrong - this is still a big vulnerability that should be taken seriously, but it’s not exactly as scary as it seems at first glance. According to OpenSSH’s official patch notes:
Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon.
Exploitation on non-glibc systems is conceivable but has not been examined. Systems that lack ASLR or users of downstream Linux distributions that have modified OpenSSH to disable per-connection ASLR re-randomisation (yes - this is a thing, no - we don't understand why) may potentially have an easier path to exploitation. OpenBSD is not vulnerable.
Additionally, macOS and Windows have their own versions of OpenSSH server that may also be affected by this vulnerability; however, this has not been confirmed by either the OpenSSH or Qualys teams. No “Proof of Concept” exploit code has been released for this vulnerability and no exploits have been observed in the wild at this time.
Affected versions:
OpenSSH servers running on Linux/glibc systems with ASLR (most modern Linux distributions)
- sshd versions older than 4.4p1
- sshd versions between 8.5p1 and 9.7p1 (inclusive)
What Should I Do?
Identify any Linux systems running vulnerable versions of OpenSSH in your environment, especially systems exposed to the internet. Don’t forget about any IoT devices running Linux - these may not be as easily patchable, but identifying these systems and checking vendor documentation may help you understand if these systems are vulnerable. If you need some help identifying which openssh-server version your systems are running, see this helpful tutorial.
Running the commandsshd -Vis the simplest way to check your OpenSSH server version.
Once you’ve identified systems that need patching, apply the latest patches from OpenSSH (9.8p1).
If you are unable to apply patches, consider disabling/uninstalling the sshd service or limiting access to the service to very specific devices and/or IP addresses. Alternatively, settingLoginGraceTimeto 0 in the sshd configuration file (located at /etc/ssh/sshd_config) will mitigate the remote code execution risk of this exploit, but will expose sshd to a denial of service (annoying, but more desirable than RCE for sure).
If you see consistent and repeated “Timeout before authentication” messages in the logs for affected devices, this may be an indication of attempts at exploitation.
Distro-specific notices:
How Blumira Can Help
Blumira has several detections that may help uncover unexpected or suspicious SSH activity:
- Unix/Linux: Failed SSH Connection Attempt (default disabled)
- SSH Connection from Public IP
Note: since Unix/Linux: Failed SSH Connection Attempt is default disabled, you will need to enable manually in the Blumira app if not done so already.
Blumira continues to actively monitor this issue, and look for ways that we can detect any stage of exploitation of these vulnerabilities.
If you are an MSP and not already using Blumira, please submit a request for a “free for internal use” NFR account.
Blumira’s Free SIEM is easy to deploy; IT and security teams can start seeing immediate security value for their organizations.
