Re: Announce: OpenSSH 9.8 released

[Solar Designer <solar () openwall com>]

Some nitpicks:

CVE-2006-5051 found by Mark Dowd, which was the original bug that got
relatively recently reintroduced as CVE-2024-6387, still has in its
description an erroneous reference to GSSAPI:

> Signal handler race condition in OpenSSH before 4.4 allows remote
> attackers to cause a denial of service (crash), and possibly execute
> arbitrary code if GSSAPI authentication is enabled, via unspecified
> vectors that lead to a double-free.

It was understood back in 2006 that this bug's exposure did not in fact
depend on GSSAPI:

https://bugzilla.redhat.com/show_bug.cgi?id=208347

> Josh Bressers 2006-09-28 15:17:17 UTC
>
> I've done some analysis of this issue and received a mail from Mark Dowd
> regarding this vulnerability.  The upstream details are misleading.
>
> The problem is that the signal handling in openssh does quite a lot and can
> introduce a race condition during cleanup.  This flaw could possibly cause a
> double free condition within the kerberos cleanup code.  The GSSAPI code is
> completely harmless, upstream calling this issue a GSSAPI issue leads me to
> believe they did not analyze, nor try to understand this issue.
>
> There is also PAM cleanup code which is executed.  This PAM source hasn't been
> investigated so the possible outcome is currently unknown.

I suggest removing " if GSSAPI authentication is enabled" from
CVE-2006-5051 description.  Maybe someone reading this can correct that.

Maybe I pay too much attention to historical detail, but this error in
CVE-2006-5051 did cause the question of GSSAPI (ir)relevance to come up
in CVE-2024-6387 discussions at least twice (that I know of).

On Mon, Jul 01, 2024 at 02:10:04AM -0600, Damien Miller wrote:
> 2) Logic error in ssh(1) ObscureKeystrokeTiming
>
> In OpenSSH version 9.5 through 9.7 (inclusive), when connected to an
> OpenSSH server version 9.5 or later, a logic error in the ssh(1)
> ObscureKeystrokeTiming feature (on by default) rendered this feature
> ineffective - a passive observer could still detect which network
> packets contained real keystrokes when the countermeasure was active
> because both fake and real keystroke packets were being sent
> unconditionally.
>
> This bug was found by Philippos Giavridis and also independently by
> Jacky Wei En Kung, Daniel Hugenroth and Alastair Beresford of the
> University of Cambridge Computer Lab.
>
> Worse, the unconditional sending of both fake and real keystroke
> packets broke another long-standing timing attack mitigation. Since
> OpenSSH 2.9.9 sshd(8) has sent fake keystoke echo packets for
> traffic received on TTYs in echo-off mode, such as when entering a
> password into su(8) or sudo(8). This bug rendered these fake
> keystroke echoes ineffective and could allow a passive observer of
> a SSH session to once again detect when echo was off and obtain
> fairly limited timing information about keystrokes in this situation
> (20ms granularity by default).
>
> This additional implication of the bug was identified by Jacky Wei
> En Kung, Daniel Hugenroth and Alastair Beresford and we thank them
> for their detailed analysis.
>
> This bug does not affect connections when ObscureKeystrokeTiming
> was disabled or sessions where no TTY was requested.

Dug Song and I designed the original fake keystroke echo packets
mitigation, and per our advisory/article back then this was "initially
applied to OpenSSH starting with version 2.5.0.  OpenSSH 2.5.2 contains
the more complete versions of the fixes and solves certain
interoperability issues associated with the earlier versions."

https://www.openwall.com/articles/SSH-Traffic-Analysis

After the 9.8 release, I've added an update (clearly marked as such) to
the article above to refer to the issue reintroduction and the new fix.
I was also surprised by the reference to 2.9.9 above, so I checked
OpenSSH-portable commits.  To me, our original references to 2.5.x look
correct, and I have no idea where 2.9.9 came from.

Luckily, those old version references are not part of the CVE-2024-39894
description, so nothing to correct there.

Alexander