Bug 1227217 (CVE-2024-6409)

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