RCE vulnerability in OpenSSH – RegreSSHion (CVE-2024-6387)

TL;DR

The Qualys Threat Research Unit has found a high-severity vulnerability, filed under CVE-2024-6387, affects OpenSSH (Open Secure Shell), a networking utility often used for remote server management and secure communication over insecure networks.

• CVE-2024-6387 affects the OpenSSH server on glibc-based Linux systems.
  • Versions before 4.4p1 and versions 8.5p1 to but not including 9.8p are impacted.
• OpenBSD systems are not affected by this CVE.
• It is advised to upgrade to OpenSSH 9.8 or later to remediate this vulnerability and to restrict access to trusted networks and users.

The vulnerability – CVE-2024-6387

https://nvd.nist.gov/vuln/detail/CVE-2024-6387

CVSSv3.1 Base Score: 8.1 High

Metrics: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

The Qualys Threat Research Unit discovered CVE-2024-6387. The CVE, dubbed regreSSHion, is a regression of CVE-2006-5051 reported in 2006. A once-fixed CVE resurfacing in a later version, OpenSSH 8.5p1 released in October 2020.

This highlights the importance of regression testing to prevent vulnerabilities resurfacing. Versions before 4.4p1 are also vulnerable unless patches for CVE-2006- 5051 and CVE-2008-4109 have been applied.

The CVE is a high-severity remote unauthenticated code execution vulnerability affecting glibc-based Linux systems. The flaw results from importer input validation in OpenSSH’s handling of SSH connections.

Does CVE-2024-6387 affect me?

There has been a lot of talk on various infosec news feeds about the RegreSSHion vulnerability.

This vulnerability could allow a persistent attacker who has either enumerated or guessed a vulnerable version of SSH with a specific setting to gain full system access. This allows malicious users to execute arbitrary code with the highest of privileges. This leaves vulnerable systems open to malware, ransomware, Denial of Service (DoS) attacks and other attacks.

There has been a fair amount of debate if this vulnerability will become widespread.

While it is not an instant exploit and may require time and a relatively noisy approach, its potential impact must be considered. Due to its challenging nature even skilled attackers may require numerous attempts for a successful attack. However, organisations with mature security measures and resources might detect the signs of such an attack. This issue should be a concern for all, regardless of their current security posture.

BUT it is important to understand this is still a publicly exploitable vulnerability, although some say that due to its complexity it is unlikely to be widespread, or that there are numerous limiting factors diminishing the high severity. However, given the speed of Proof of Concepts and ‘check scripts’ produced, it could indicate otherwise.

This does not diminish the fact there are thousands of legacy machines and technical debt still out there and that preventative measures if SSH is publicly facing, can be circumvented. There are potentially many machines that have been neglected in the past few years for a variety of reasons.

It is in an organisation’s best interests to not gamble on a series of variables that may or may not leave data vulnerable.

What mitigating factors are there?

Patch Patch Patch!

The solution is simple. Users are advised to upgrade to OpenSSH 9.8 or later. Patch and move on. If you are impacted by one of the vulnerable versions, then the best advice is the patch your machine promptly.

If you are uncertain if you are impacted, then patching would be the safer option. If you are certain you are not impacted, then ask yourself what is the harm in patching and what is preventing you from doing so?

Also ask yourself the question: do I need to expose SSH to the untrusted internet? If the answer is “no” then remove or restrict the service by adjusting your firewall rules accordingly. In an ideal world, SSH should  only be visible to trusted networks. Numerous limiting factors may be applied and should be considered such as Access Control Lists (ACL) or Virtual Private Networks (VPN).

Patches from Linux distribution security bulletins including but not limited to Ubuntu, Debian and RedHat have been provided.

Qualys have done an excellent technical write up of the issue at https://www.qualys.com/regresshion-cve-2024-6387/.

The advisory provides some numerous options to mitigating the RegreSSHion vulnerability: qualys.com/2024/07/01/cve-2024-6387/regresshion.txt:

1. Restrict Access: Limit SSH access to trusted networks and users only. Implement network access controls to restrict who can connect to your SSH servers.
2. Use Strong Authentication: Enhance security by using key-based authentication and disabling password-based logins where possible.
3. Monitor and Audit: Regularly monitor SSH access logs for unusual activity and audit your SSH configuration to ensure it follows security best practices.

Many of the advisories refer to this Qualys mitigating factor:

“Finally, if sshd cannot be updated or recompiled, this signal handler race condition can be fixed by simply setting LoginGraceTime to 0 in the configuration file.

This makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but it makes it safe from the remote code execution presented in this advisory.”