RHEL 9 OpenSSH packages affected by remote code execution flaw

A new security vulnerability, CVE-2024-6409, has been discovered in OpenSSH packages included in Red Hat Enterprise Linux (RHEL) 9 and certain versions of Fedora.
RHEL 9 OpenSSH packages affected by remote code execution flaw

A new vulnerability in OpenSSH packages has been discovered, potentially allowing remote code execution on Red Hat Enterprise Linux (RHEL) 9 systems.

This follows the recent identification of a critical flaw in OpenSSH called regreSSHion, identified as CVE-2024-6387, which also allowed for remote code execution (RCE).

The latest vulnerability, CVE-2024-6409, shares similarities with its predecessor but is considered less dangerous as it manifests after a privilege reset in a child process initiated by the SSH server.

This flaw is found in OpenSSH packages included in RHEL 9, based on the OpenSSH 8.7 release. The issue also affects Fedora Linux 36 and 37, which are based on OpenSSH 8.7 and 8.8 releases.

Nature of the vulnerability

CVE-2024-6409 arises from a race condition in the SIGALRM interrupt handler, similar to the previous issue. A race condition occurs when multiple processes or threads compete to access and manipulate shared data concurrently, leading to unpredictable results. This specific vulnerability is triggered by the execution of functions not designed for asynchronous use in signal handlers, such as syslog(). When the SIGALRM signal interrupts code execution, it can damage internal memory structures managed by malloc.

The new vulnerability differs in its specific cause. The race condition here is triggered by a call to cleanup_exit() within the grace_alarm_handler() signal handler. While cleanup_exit() can be used in asynchronously executed code within the core OpenSSH codebase, a patch applied to RHEL 9 and Fedora packages introduces a call to cleanup_exit() for generating audit events, which is unsafe for signal handlers.

Impact and mitigation

According to an announcement from Solar Designer (Alexander Peslyak) on Openwall, “The main difference from CVE-2024-6387 is that the race condition and RCE potential are triggered in the privsep child process, which runs with reduced privileges compared to the parent server process. So immediate impact is lower.” This means that while the vulnerability does allow for remote code execution, the child process’s reduced privileges mitigate some of the potential damage.

However, the potential for exploitation remains significant. If only one of these vulnerabilities is fixed or mitigated, the other becomes more relevant. As Designer explains, “It may also be possible to construct an exploit that would work against either vulnerability probabilistically, which could decrease attack duration or increase success rate.”

The vulnerability does not affect current Fedora releases, starting from Fedora 38, which uses newer OpenSSH versions without the problematic cleanup_exit() call. Unfortunately, the previous workaround for CVE-2024-6387, involving the -e option in sshd to disable syslog logging, does not address this new issue. Instead, setting the LoginGraceTime=0 parameter in sshd_config is recommended to block the vulnerability.

Response and disclosure

The vulnerability was disclosed to distros on June 26, 2024, by Solar Designer, with further analysis and confirmation by Qualys. According to Designer, “Qualys later found another issue with the audit patch, which is currently believed to be mostly non-security.”

Solar Designer added, “I’m sorry for not disclosing CVE-2024-6409 on the same day as CVE-2024-6387, which would have saved many of us time (me included).”

As evidenced by these recent discoveries, the use of dynamic memory allocation functions within signal handlers poses a significant risk.

While the CVE-2024-6409 vulnerability presents a lower immediate risk due to the reduced privileges of the affected process, its potential for exploitation remains a serious concern. As we already saw with the original regreSSHion release, exploits were being made not even a day after publishing the main findings.

Posted by Alex Ivanovs

Alex is the lead editor at Stack Diary and covers stories on tech, artificial intelligence, security, privacy and web development. He previously worked as a lead contributor for Huffington Post for their Code column.