Get a demo

Voyager18 (research)

OpenSSH again? How to fix CVE-2024-7589 in FreeBSD

CVE-2024-7589 is a critical vulnerability in OpenSSH that impacts all supported versions of FreeBSD. Here's what you need to know.

Yair Divinsky | August 13, 2024

CVE-2024-7589 is a critical vulnerability in OpenSSH that impacts all supported versions of FreeBSD. This flaw is particularly concerning due to its potential for remote code execution with root privileges, making it a significant security risk for organizations relying on FreeBSD systems.

In this post, we will break down what this vulnerability entails, its potential impact, and how to protect your systems from exploitation. 

TL;DR

Affected products: 

All supported versions of FreeBSD with OpenSSH enabled 

Product category: 

OS Vulnerability 

Severity: 

Critical 

Type: 

Remote code execution (RCE) 

Impact: 

Potential full system compromise with root privileges 

PoC: 

No public proof-of-concept (PoC) available yet 

Exploit in the wild 

No confirmed reports of active exploitation yet 

CISA Catalog 

No 

Remediation action 

Apply the provided patches via freebsd-update or manually patch and recompile the source code: 

  • 14.1-RELEASE-p3 
  • 14.0-RELEASE-p9 
  • 13.3-RELEASE-p5) 

Temporary mitigation: Set LoginGraceTime to 0. 

MITRE advisory 

Read more 

What is CVE-2024-7589?

CVE-2024-7589 is a security vulnerability discovered in the OpenSSH implementation used by FreeBSD. FreeBSD, a well-known open-source operating system, recently issued an emergency patch to fix a critical vulnerability in OpenSSH.

According to the FreeBSD advisory, this security flaw, tracked as CVE-2024-7589, could allow remote attackers to gain unauthorized access and execute arbitrary code with elevated privileges on affected FreeBSD systems.  

The issue arises from a race condition in the SSH daemon (sshd), specifically when handling asynchronous signals in the context of blacklistd, a service designed to block malicious IPs.

This vulnerability can be triggered during the LoginGraceTime window, a critical period where the SSH server waits for user authentication. 

The root of the problem is that a signal handler within sshd may call a logging function that is not asynchronous signal-safe. This flaw was identified as another instance of the issue previously addressed in CVE-2024-6387. 

The vulnerability arises from a race condition triggered in specific scenarios. When the LoginGraceTime period ends, the signal handler in sshd(8) runs within the process’s privileged context. Since this code operates with full root privileges and lacks sandboxing, it becomes susceptible to exploitation. 

Consequently, an attacker could exploit this race condition, potentially leading to unauthenticated remote code execution as root, thereby compromising the entire system. 

 

Does CVE-2024-7589 affect me?

If you are running any version of FreeBSD with OpenSSH enabled, your system is vulnerable. The advisory specifically mentions that all supported versions of FreeBSD are affected. This includes both stable and release branches across multiple versions, including 14.1-STABLE, 14.1-RELEASE, 14.0-RELEASE, 13.3-STABLE, and 13.3-RELEASE. 

Given the severity of this vulnerability, it is critical for administrators to assess their systems immediately and determine if they are running an affected version of FreeBSD with OpenSSH. 

 

Has CVE-2024-7589 been actively exploited in the wild?

While there have been no confirmed reports of active exploitation at the time of this writing, the potential for exploitation is high.

This vulnerability is similar to the one addressed in the “regresshion” vulnerability (CVE-2024-6387), which also involved remote code execution risks in OpenSSH.

Given the critical nature of this flaw and the full root access it can potentially provide, it is plausible that attackers could develop exploits targeting this vulnerability if they haven’t already. 

 

How to fix CVE-2024-7589

Given the severity of this vulnerability, it’s essential for users to understand the risks and take prompt action to secure their systems. 

To mitigate this vulnerability, it is strongly recommended to update your FreeBSD systems to the latest patched versions as soon as possible. The FreeBSD Security Team has provided patches for the affected branches and versions (14.1-RELEASE-p3, 14.0-RELEASE-p9, 13.3-RELEASE-p5), and the updates can be applied using the freebsd-update utility or by manually applying the provided source code patches. 

If immediate patching is not possible, a temporary workaround involves setting LoginGraceTime to 0 in the sshd_config file. This will disable the window for exploiting the race condition but could lead to a denial of service due to the exhaustion of all MaxStartups connections. 

 

To apply the patch: 

1. Binary Patch: 

– Run: 

# freebsd-update fetch 
# freebsd-update install

2. Source Code Patch: 

– Download and verify the patch: 

# fetch https://security.FreeBSD.org/patches/SA-24:08/openssh.patch 
# fetch https://security.FreeBSD.org/patches/SA-24:08/openssh.patch.asc 
# gpg –verify openssh.patch.asc  

– Apply the patch: 

 # cd /usr/src 
# patch < /path/to/patch

– Recompile the operating system.  

Make sure to restart sshd after patching! 

For cases where updating the system is not immediately feasible: 

Mitigate the risk of exploitation by setting LoginGraceTime to 0 in the sshd(8) configuration file (/etc/ssh/sshd_config): 

  • Edit the Configuration File – Open /etc/ssh/sshd_config in a text editor. 
  • Set LoginGraceTime to 0 – Find the LoginGraceTime directive and set its value to 0. 
  • Restart sshd(8) – After making the change, restart the sshd(8) daemon using the service sshd restart command. 

 

Further reading

Each new vulnerability is a reminder of where we stand and what we need to do better. Check out the following resources to help you maintain cyber hygiene and stay ahead of the threat actors: 

  1. Q1 2024 Vulnerability Watch
  2. The MITRE ATT&CK framework: Getting started
  3. The true impact of exploitable vulnerabilities for 2024
  4. Vulnerability disclosure policy (and how to get it right)
  5. How to properly tackle zero-day threats

Get rid of silos;

Start owning exposure risk

Test drive the leader in exposure risk management