9.3 High
CVSS2
Attack Vector
NETWORK
Attack Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:N/AC:M/Au:N/C:C/I:C/A:C
8.1 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
HIGH
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
9.1 High
AI Score
Confidence
Low
0.791 High
EPSS
Percentile
98.3%
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.
<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.
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.
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:
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.”
The post RCE vulnerability in OpenSSH – RegreSSHion (CVE-2024-6387) first appeared on Pen Test Partners.
9.3 High
CVSS2
Attack Vector
NETWORK
Attack Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:N/AC:M/Au:N/C:C/I:C/A:C
8.1 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
HIGH
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
9.1 High
AI Score
Confidence
Low
0.791 High
EPSS
Percentile
98.3%