From oss-security

The below excepts are about an extra issue (beyond CVE-2024-6409) - the
audit patch's logging of SSH host key fingerprints apparently being
broken at least on RHEL 9. This issue is only indirectly related to
CVE-2024-6409 because it explains why more async-signal-unsafe calls are
made than would have been otherwise.

On Thu, Jul 04, 2024 at 01:40:34AM +0000, Qualys Security Advisory wrote:
> we found more information on the following:
>
> On Wed, Jun 26, 2024 at 11:06:43AM +0000, Qualys Security Advisory wrote:
> > - The call to destroy_sensitive_data() may or may not be a problem,
> > because the "sensitive data" (private keys) were already destroyed in
> > the unpriv child at that point.
>
> It is a problem: destroy_sensitive_data() calls malloc functions many
> times (especially free()) because even if only the public keys remain in
> sensitive_data.host_keys, they are still passed to sshkey_free().
>
> In fact, destroy_sensitive_data() even ends up calling syslog() itself:
> PRIVSEP(audit_destroy_sensitive_data()) calls mm_request_send(), which
> can fail if the priv/parent process already _exit()ed, so fatal_f() is
> called, which calls mm_log_handler(), which also fails because the priv/
> parent process _exit()ed, so fatal_f() is called again, but this time it
> calls syslog().
>
> If you are wondering why destroy_sensitive_data() calls
> PRIVSEP(audit_destroy_sensitive_data()) in the first place, we were
> wondering too, because this should happen only if one of the keys is
> private, and no private key should remain in the unpriv/child process!
> This is actually a bug in sshkey_is_private(): for ed25519 keys, this
> function checks ed25519_pk, which is the public key! It should check
> ed25519_sk instead, which is the secret/private key.

On Sun, Jul 07, 2024 at 11:21:37PM +0200, Solar Designer wrote:
> Thank you for reporting this to distros. I don't see this function in
> any upstream version at all - do you? I see it being added via
> openssh-7.6p1-audit.patch in Red Hat's package. I don't know if an
> equivalent patch is maybe also added in some other distros?
>
> As to security consequences, at first my concern was this could leave
> secret host keys around in privsep child. However, upon a closer look
> the only thing audit_destroy_sensitive_data() does is log a message, so
> the only impact is erroneous audit logging.

> Actual processing of keys is untouched by this patch, so probably
> remains correct.

On Mon, Jul 08, 2024 at 05:23:22PM +0200, Solar Designer wrote:
> On Mon, Jul 08, 2024 at 03:00:37PM +0000, Qualys Security Advisory wrote:
> > On Mon, Jul 08, 2024 at 03:35:29PM +0200, Solar Designer wrote:
> > > [...] with RH's original code
> > > I saw the same key's destruction logged 3 times. I think some of those
> > > were not from the unprivileged child, and actually made sense. So I was
> > > hoping that fixing the check from pk to sk would suppress only the
> > > erroneous logging from the unprivileged child, but in my testing it
> > > suppressed all of it.
> >
> > [...] I think that I have
> > found the solution to this mystery, but I have not yet investigated the
> > consequences (if any): the private host keys are "shielded" as soon as
> > they are loaded (by sshkey_shield_private()), which means that, to the
> > (non-buggy) tests in sshkey_is_private(), they look like public keys,
> > but the private part is actually there, in another part of the key
> > structure, in encrypted form.

> The shielding was added upstream in:
>
> commit 4f7a56d5e02e3d04ab69eac1213817a7536d0562
> Author: djm@openbsd.org <djm@openbsd.org>
> Date: Fri Jun 21 04:21:04 2019 +0000
>
> upstream: Add protection for private keys at rest in RAM against
>
> speculation and memory sidechannel attacks like Spectre, Meltdown, Rowhammer
> and Rambleed. This change encrypts private keys when they are not in use with
> a symmetic key that is derived from a relatively large "prekey" consisting of
> random data (currently 16KB).
>
> which is newer than 7.6p1 that openssh-7.6p1-audit.patch was presumably
> based on. So it is possible that this audit logging was more functional
> initially (sans this bug for ed25519 you found), but mostly broke when
> it was rebased on newer versions without consideration for the change
> above. However, that's just a guess, which I did not confirm. A way to
> confirm it could be to test a Red Hat package that already has the audit
> patch, but does not yet have upstream's shielding. Since the above
> upstream commit isn't in 8.0 (it's about 1 week newer than V_8_0 tag),
> maybe RHEL 8 is suitable for this test (its package is based on 8.0p1).
>
> ... and indeed, on a RHEL 8 rebuild system I see "msg='op=destroy
> kind=server fp=SHA256:" /var/log/audit/audit.log lines with 3 different
> fingerprint values, presumably corresponding to the different key types.
> This is different from the RHEL 9 rebuild system I checked before, where
> only one fingerprint value would be seen despite of the system also
> having 3 different host key types.