FreeBSD Releases Urgent Patch for High-Severity OpenSSH Vulnerability

The maintainers of the FreeBSD Project have released security updates to address a high-severity flaw in OpenSSH that attackers could potentially exploit to execute arbitrary code remotely with elevated privileges.

The vulnerability, tracked as CVE-2024-7589, carries a CVSS score of 7.4 out of a maximum of 10.0, indicating high severity.

“A signal handler in sshd(8) may call a logging function that is not async-signal-safe,” according to an advisory released last week.

✔ Approved From Our Partners

Protect and backup your data using AOMEI Backupper. AOMEI Backupper takes secure and encrypted backups from your Windows, hard drives or partitions. With AOMEI Backupper you will never be worried about loosing your data anymore.

Get AOMEI Backupper with 72% discount from an authorized distrinutor of AOMEI: SerialCart® (Limited Offer).

➤ Activate Your Coupon Code

“The signal handler is invoked when a client does not authenticate within the LoginGraceTime seconds (120 by default). This signal handler executes in the context of the sshd(8)’s privileged code, which is not sandboxed and runs with full root privileges.”

OpenSSH is an implementation of the secure shell (SSH) protocol suite, providing encrypted and authenticated transport for a variety of services, including remote shell access.

CVE-2024-7589 has been described as an “another instance” of a problem that’s referred to as regreSSHion (CVE-2024-6387), which came to light early last month.

“The faulty code in this case is from the integration of blacklistd in OpenSSH in FreeBSD,” the project maintainers said.

“As a result of calling functions that are not async-signal-safe in the privileged sshd(8) context, a race condition exists that a determined attacker may be able to exploit to allow an unauthenticated remote code execution as root.”

Users of FreeBSD are strongly advised to update to a supported version and restart sshd to mitigate potential threats.

In cases where sshd(8) cannot be updated, the race condition issue can be resolved by setting LoginGraceTime to 0 in /etc/ssh/sshd_config and restarting sshd(8). While this change makes the daemon vulnerable to a denial-of-service, it safeguards it against remote code execution.

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.