TL;DR: A new OpenSSH vulnerability has been discovered, but the impact on Claroty products is limited. We are taking immediate action to ensure your environments remain secure. Updates and mitigations are in progress, and all products are either unaffected or have a clear remediation plan.
We are writing to inform you about a critical vulnerability in OpenSSH, known as the regreSSHion vulnerability. This vulnerability allows for remote unauthenticated code execution on affected systems and poses significant risks. We are committed to ensuring the security of our products and your environments.
The Qualys Threat Research Unit discovered a Remote Unauthenticated Code Execution (RCE) vulnerability in OpenSSH’s server (sshd) in glibc-based Linux systems. The CVE assigned to this vulnerability is CVE-2024-6387. The vulnerability, which is a signal handler race condition in OpenSSH’s server (sshd), allows unauthenticated remote unauthenticated code execution as root on glibc-based Linux systems, which presents a significant security risk.
OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition 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, which made a previously unsafe function secure.
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.
OpenBSD systems are unaffected by this bug, as OpenBSD developed a secure mechanism in 2001 that prevents this vulnerability.
The detailed analysis can be found in the Qualys blog post: regreSSHion Vulnerability Details.
Given the widespread use of OpenSSH for secure communications, this vulnerability is of critical concern, particularly for organizations utilizing remote access tools. However, it is important to note that this vulnerability is challenging to exploit due to its remote race condition nature, requiring multiple attempts for a successful attack.
Risk Level: Very low
Details: SSH is blocked outside our private network on all our servers.
Mitigation Actions: We have started updating the SSH version on all our servers to remediate this vulnerability, with completion expected by Sunday, July 7th.
Versions 4.9.1 and Lower (on ClarotyOS): Not affected.
Versions 4.9.1 and Lower (on CentOS / RHEL): Not affected. However, since the operating system is not maintained by Claroty, and other software packages could have installed this vulnerable service, users will need to check if action is required.
Versions 5.0 and Higher (5.0, 5.0.10): Affected by this CVE.
Mitigation Actions:
Customers on version 5.0.0 will be able to upgrade to a new version (5.0.1) that includes a security update on Friday, July 5th.
Customers on version 5.0.10 will be able to upgrade to a new version (5.0.11) that includes a security update on Thursday, July 11th.
For customers on version 4.9.1 we recommend waiting for the release of version 5.0.11 for migration to the new ClarotyOS.
For customers utilizing their own managed CentOS or RedHat Enterprise Linux (RHEL) Installations, they should check if the OpenSSH (sshd) service is installed, and update these packages accordingly. Please see the section below titled How to check if your system contains the regreSSHion vulnerability. If customers need assistance in checking for this, please contact your CSM or Claroty Support.
Versions 3.7 and Lower: Not affected. However, since the operating system is not maintained by Claroty, and other software packages could have installed this vulnerable service, users will need to check if action is required.
Version 4.0: Affected by this CVE.
Mitigation Actions:
For on-prem deployments, Claroty will release an Upgrade Version with a security update by Thursday, July 18th (version 4.0.1).
For AWS deployments, it is possible that a redeployment will be required.
Claroty is currently investigating and will give further guidance by Friday July 5th.
If a customer is utilizing their own managed CentOS or RedHat Enterprise Linux (RHEL) Installations, they should check if the OpenSSH (sshd) service is installed, and update these packages accordingly. Please see the section below titled How to check if your system contains the regreSSHion vulnerability. If customers need assistance in checking for this, please contact your CSM or Claroty Support.
Execute the following command at the command line:
# Check OpenSSH version
sshd -V
The output should be similar to:
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
If the openSSH version is lower than 4.4p1 (4.4p1 is safe) or 8.5p1 and higher (8.5p1 is not safe), it is vulnerable and needs to be updated.
Versions within the range of 4.4p1 <= OpenSSH < 8.5p1 do not contain this vulnerability.
From an analysis conducted against our entire customer base, we’ve found very few vulnerable devices. To help investigate the impact of this vulnerability, CVE-2024-6387 will be added to our products:
For xDome and xDome for Healthcare (formerly Medigate) customers: The threat intelligence feed in xDome was updated today, and should appear in the dashboard. The regreSSHion vulnerability will be added to xDome’s vulnerability detection module tomorrow. After this, xDome can help identify devices containing the vulnerability. Please note, however, that passive detection alone is unable to identify this vulnerability.
For CTD and xDome Secure Access (formerly SRA) customers: The vulnerability will be added to the forthcoming bundle 91.
We remain dedicated to maintaining the highest security standards and ensuring the safety of your operations. If you have any questions or need further assistance, please do not hesitate to contact our support team.
H-ISAC Alert Warns of TeamViewer Compromise
Rockwell Automation Users Urged to Disconnect ICS from Internet—Immediately
Black Basta Ransomware Used Against 500 Critical Infrastructure Organizations
Interested in learning about Claroty's Cybersecurity Solutions?