Bugzilla – Bug 1227217
VUL-0: CVE-2024-6409: openssh: cleanup_exit problem in 8.7 and 8.8
Last modified: 2024-07-09 08:59:47 UTC
Yes, Marcus is right. I just checked that we have: openssh 7.2 in SLE-12-SP5 openssh 8.1 in SLE-15-SP2 openssh 8.4 in SLE-15-SP3 openssh 9.6 in SLE-15-SP6, ALP, Factory So they shouldn't be affected by this. Anyway, since the openssh package is so heavily patched, I checked the sources just in case and I can confirm they're not affected by this.
pubkic via oss-sec Hi, Today is the coordinated release date to publicly disclose a related issue I found during review of Qualys' findings, with further analysis by Qualys. My summary is: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child due to a race condition in signal handling OpenSSH versions 8.7 and 8.8 and the corresponding portable releases 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 and may call other async-signal-unsafe functions. 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. Relevantly, this patch is found in RHEL 9 (and its rebuild/downstream distributions), where the package is based on OpenSSH 8.7p1. The audit patch is also found in Fedora, so the package versions that were based on 8.7p1 and 8.8p1 are affected. Per change log, it appears that out of Fedora releases only 36 and 37 were affected, as well as some updates maybe starting with those for 35 and until those for 37. These versions are now end-of-life, and Fedora 38+ has moved to newer upstream OpenSSH that doesn't make the problematic cleanup_exit() call. 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. However, there may be differences in exploitability of these vulnerabilities in a particular scenario, which could make either one of these a more attractive choice for an attacker, and if only one of these is fixed or mitigated then the other becomes more relevant. In particular, the "LoginGraceTime 0" mitigation works against both issues, whereas the "-e" mitigation only works against CVE-2024-6387 and not (fully) against CVE-2024-6409. 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. That said, actual exploitation of CVE-2024-6409 has not yet been attempted and thus has not been proven. I brought this extra issue to distros on June 26 and Qualys confirmed and completed most of the analysis later same day. Qualys later found another issue with the audit patch, which is currently believed to be mostly non-security. I include it closer to the end of this message. 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.
no need for fix