Impact Analysis: regreSSHion OpenSSH Vulnerability (CVE-2024-6387) 

On July 1, 2024, the Qualys Threat Research unit publicly reported they had found a vulnerability in OpenSSH’s server that leads to unauthenticated remote code execution (RCE) with root privileges. This has been given the number CVE-2024-6387 and nicknamed “regreSSHion,” with a CVSS score of 8.1 and a high severity categorization. While the vulnerability is high impact, the complexity of the attack leads us to believe it is unlikely to see mass exploitation. 

NetSPI’s take 

Save the panic button for the next one. The exploitability for commonly deployed versions of OpenSSH is currently considered low. That could change in the coming days and weeks and so deliberate action to patch and monitor your attack surface for listening OpenSSH servers is still recommended. 

What is OpenSSH?

OpenSSH is a set of networking tools that provide encrypted communication to ensure secure remote access and data transfer over networks. OpenSSH is widely used in various operating systems, cloud services, and development environments. This vulnerability is in the OpenSSH server (sshd) and only affects the OpenSSH server on glibc-based Linux systems. 

CVE-2024-6387 details

CVE-2024-6387 (“regreSSHion”) reintroduces a previous vulnerability from 2006 (CVE-2006-5051) due to the removal of a critical line of code. The vulnerability itself is a signal handler race condition in OpenSSH’s server.  Meaning, when a client does not authenticate within the time specified by LoginGraceTime (120 seconds by default), it causes sshd’s SIGALRM handler to be called asynchronously. The signal handler calls various functions that are not async-signal-safe and this eventually leads heap corruption and ultimately arbitrary code execution.

In the simplest terms, OpenSSH incorrectly handles signal management which could result in a remote attacker bypassing authentication and remotely accessing systems as a highly privileged user without proper credentials. This would allow a threat actor to have complete control of the system and an entry point to move further into the network. The consequences at that point depend on the system’s stored data and position in the network.

Exploitation difficulties

Fortunately, the complexity of the attack makes the successful exploitation a long process. Qualys Threat Research unit have reported that they have only been successful on exploiting 32-bit systems and this takes approximately 10,000 connections and 6-8 hours when targeting the latest Debian version in a lab environment.

For 64-bit systems there has currently been no known successful exploitation, this is likely due to it being exponentially more complex and therefore takes longer. It is estimated that successful exploitation of a 64-bit system would take “less than a week.” 

Proof of concept code has been made publicly available via a GitHub repository. NetSPI’s proactive security experts, The NetSPI Agents, are currently working through the lengthy steps to test and validate the exploit.

Which versions of OpenSSH are affected?

As of July 2, the OpenSSH server (sshd) versions below are impacted: 

• OpenSSH versions earlier than 4.4p1 are vulnerable unless they are patched for CVE-2006-5051 and CVE-2008-4109. 
• Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable due to a transformative patch for CVE-2006-5051. 
• The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function. 
• This vulnerability only affects the OpenSSH server running on glibc-based Linux system but does NOT affect OpenBSD systems. 

Remediation guidance for CVE-2024-6387

It is recommended to update to the latest version of OpenSSH where possible.  

If updating OpenSSH is not possible, it is recommended to restrict public access to any system running OpenSSH server. 

Review your internal Linux systems and verify if you are running any of the affected OpenSSH server (sshd) versions. Apply available patches.

Beyond patching, there are additional steps you can take to protect yourself against exploitation: 

• Apply firewall rules to limit external exposure to internet facing SSH servers. 
• Specifically, administrators are advised to apply the recommended mitigations via sshd_config modification as an additional safeguard. 
• NetSPI ASM can identify public-facing SSH servers that are likely impacted to help prioritize investigation efforts. 

We’ve also heard of some administrators setting up fail2ban to block repeated attempts instead of changing the login settings. This seems like an interesting alternative to setting LoginGraceTime to 0 in the sshd config file.

Additional guidelines for discovery and remediation can be found here: 

• https://www.cve.org/CVERecord?id=CVE-2024-6387 
• https://ubuntu.com/security/CVE-2024-6387 
• https://www.thestack.technology/openssh-vulnerability-cve-2024-6387/ 

Identify vulnerable versions of OpenSSH and expedite remediation with NetSPI ASM

The first step towards remediation is to identify assets at risk of exploitation. Attack surface management tools can quickly and accurately discover vulnerable versions of OpenSSH. As mentioned above, NetSPI ASM can identify public-facing SSH servers that are likely impacted to help prioritize investigation efforts. Contact the NetSPI ASM team to get started. 

References:

• https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server
• https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt
• https://github.com/zgzhang/cve-2024-6387-poc