Backport the security patch of CVE-2024-39894

[Crispy-fried-chicken]

Hi,
we find the recurring vulnerability which shares the similarity of CVE-2024-39894 in you project with the version of release/14.0.0 and release/13.3.0. The patch of this CVE is openssh/openssh-portable@146c420 and we find that you've already fix it in the main branch, which is the commit b81424a. Is there a need to backport it?

[jlduran]

It's already in stable/14, and in stable/13. Patches to releng branches must go through the Security Officer.

[Crispy-fried-chicken]

It's already in stable/14, and in stable/13. Patches to releng branches must go through the Security Officer.

So how can I do? or there is no need to backport?

[jlduran]

I can answer the easy part:

This pull request cannot be accepted as is. If you consider that this bug¹ should have received a Security Advisory, then you should follow this procedure: https://www.freebsd.org/security/.

Footnotes

1. 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. ↩

[bsdimp]

This is in all stable branches, and secteam didn't think we needed a SA for this for 14.0 (which is almost out of support)