OpenSSH bug leaves RHEL 9 and the RHELatives vulnerable

July 11, 2024 TH Author

The founder of Openwall has discovered a new signal handler race condition in the core sshd daemon used in RHEL 9.x and its various offshoots.

The new flaw, catchily dubbed CVE-2024-6409, was found by Openwall’s Alexander Peslyak, known in the security world as Solar Designer. It affects the sshd daemon versions 8.7p1 and 8.8p1, which were used in Fedora 36 and 37 as well as Red Hat Enterprise Linux 9 – and of course the various RHELatives as well.

The flaw was announced earlier this week on the oss-security mailing list, and the AlmaLinux team has already released a fix – beating the bigger players. As AlmaLinux’s Andrew Lukoshko said:

The decision to build the update and push the package to production without waiting for a CentOS Stream or RHEL update was made by our newly-formed technical steering committee, ALESCo.

It’s not long since the “regreSSHion” OpenSSH bug, which The Register covered earlier this month and which is more formally known as CVE-2024-6387. That one had broader reach, affecting OpenSSH from 8.5p1 to 9.7p1. This issue is unrelated, but it’s potentially nasty, because it affects a part of OpenSSH that’s running with reduced privileges.

Peslyak’s analysis of the issue is quite damning. He says that the affected versions…

call cleanup_exit() from grace_alarm_handler() when running in the privsep child process. cleanup_exit() was not meant to be called from a signal handler

In other words, calling a function from somewhere it shouldn’t get called from created a bug… and just like the regreSSHion bug, this potentially allows remote code execution: the ability to send code to a remote machine, and then trick that machine into running your code. The Debian project’s explanation explains the significance in plainer language: although this is a high-severity bug, it’s running in a process with separated privilges. This means that the affected code is running like an ordinary user account, not an administrative account, so the potential attack is more limited.

Peslyak continues:

The current understanding is that in those upstream versions cleanup_exit() would not actually call async-signal-unsafe functions under those conditions, but with downstream distribution patches it sometimes does. Specifically, openssh-7.6p1-audit.patch found in Red Hat’s package of OpenSSH adds code to cleanup_exit() that exposes the issue.

In other words, it looks as if some hapless coder from the IBM subsidiary introduced this bug in the company’s own version of the code. It sounds to us like Peslyak is unhappy with how the Big Purple Hat handled this:

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). I agreed for the separate coordinated release date because apparently Red Hat already had CVE-2024-6387 in the pipeline and wasn’t ready to add a fix for CVE-2024-6409 at the same time.

The good news is that (at least, in theory) nobody sensible will be affected by the Fedora issue, because those versions are both end of life: version 36 in May last year, and version 37 last December. As it was a Red Hat change, then other distros should be immune, but just to soothe shattered nerves, Canonical states that Ubuntu users need not fear, as no still-supported version uses those releases.