[v3] openssh: upgrade 9.7p1 -> 9.8p1

Release notes at https://www.openssh.com/txt/release-9.8

Security
========

This release contains fixes for two security problems, one critical
and one minor.

1) Race condition in sshd(8)

A critical vulnerability in sshd(8) was present in Portable OpenSSH
versions between 8.5p1 and 9.7p1 (inclusive) that may allow arbitrary
code execution with root privileges.

Successful exploitation has been demonstrated on 32-bit Linux/glibc
systems with ASLR. Under lab conditions, the attack requires on
average 6-8 hours of continuous connections up to the maximum the
server will accept. Exploitation on 64-bit systems is believed to be
possible but has not been demonstrated at this time. It's likely that
these attacks will be improved upon.

Exploitation on non-glibc systems is conceivable but has not been
examined. Systems that lack ASLR or users of downstream Linux
distributions that have modified OpenSSH to disable per-connection
ASLR re-randomisation (yes - this is a thing, no - we don't
understand why) may potentially have an easier path to exploitation.
OpenBSD is not vulnerable.

We thank the Qualys Security Advisory Team for discovering, reporting
and demonstrating exploitability of this problem, and for providing
detailed feedback on additional mitigation measures.

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.

Future deprecation notice
=========================

OpenSSH plans to remove support for the DSA signature algorithm in
early 2025. This release disables DSA by default at compile time.

DSA, as specified in the SSHv2 protocol, is inherently weak - being
limited to a 160 bit private key and use of the SHA1 digest. Its
estimated security level is only 80 bits symmetric equivalent.

OpenSSH has disabled DSA keys by default since 2015 but has retained
run-time optional support for them. DSA was the only mandatory-to-
implement algorithm in the SSHv2 RFCs, mostly because alternative
algorithms were encumbered by patents when the SSHv2 protocol was
specified.

This has not been the case for decades at this point and better
algorithms are well supported by all actively-maintained SSH
implementations. We do not consider the costs of maintaining DSA
in OpenSSH to be justified and hope that removing it from OpenSSH
can accelerate its wider deprecation in supporting cryptography
libraries.

This release, and its deactivation of DSA by default at compile-time,
marks the second step in our timeline to finally deprecate DSA. The
final step of removing DSA support entirely is planned for the first
OpenSSH release of 2025.

DSA support may be re-enabled in OpenBSD by setting "DSAKEY=yes"
in Makefile.inc. To enable DSA support in portable OpenSSH, pass
the "--enable-dsa-keys" option to configure.

Potentially-incompatible changes
--------------------------------

 * all: as mentioned above, the DSA signature algorithm is now
   disabled at compile time.

 * sshd(8): the server will now block client addresses that
   repeatedly fail authentication, repeatedly connect without ever
   completing authentication or that crash the server. See the
   discussion of PerSourcePenalties below for more information.
   Operators of servers that accept connections from many users, or
   servers that accept connections from addresses behind NAT or
   proxies may need to consider these settings.

 * sshd(8): the server has been split into a listener binary, sshd(8),
   and a per-session binary "sshd-session". This allows for a much
   smaller listener binary, as it no longer needs to support the SSH
   protocol. As part of this work, support for disabling privilege
   separation (which previously required code changes to disable) and
   disabling re-execution of sshd(8) has been removed. Further
   separation of sshd-session into additional, minimal binaries is
   planned for the future.

 * sshd(8): several log messages have changed. In particular, some
   log messages will be tagged with as originating from a process
   named "sshd-session" rather than "sshd".

 * ssh-keyscan(1): this tool previously emitted comment lines
   containing the hostname and SSH protocol banner to standard error.
   This release now emits them to standard output, but adds a new
   "-q" flag to silence them altogether.

 * sshd(8): (portable OpenSSH only) sshd will no longer use argv[0]
   as the PAM service name. A new "PAMServiceName" sshd_config(5)
   directive allows selecting the service name at runtime. This
   defaults to "sshd". bz2101

 * (portable OpenSSH only) Automatically-generated files, such as
   configure, config.h.in, etc will now be checked in to the portable
   OpenSSH git release branch (e.g. V_9_8). This should ensure that
   the contents of the signed release branch exactly match the
   contents of the signed release tarball.

Changes since OpenSSH 9.7
=========================

This release contains mostly bugfixes.

New features
------------

 * sshd(8): as described above, sshd(8) will now penalise client
   addresses that, for various reasons, do not successfully complete
   authentication. This feature is controlled by a new sshd_config(5)
   PerSourcePenalties option and is on by default.

   sshd(8) will now identify situations where the session did not
   authenticate as expected. These conditions include when the client
   repeatedly attempted authentication unsucessfully (possibly
   indicating an attack against one or more accounts, e.g. password
   guessing), or when client behaviour caused sshd to crash (possibly
   indicating attempts to exploit bugs in sshd).

   When such a condition is observed, sshd will record a penalty of
   some duration (e.g. 30 seconds) against the client's address. If
   this time is above a minimum configurable threshold, then all
   connections from the client address will be refused (along with any
   others in the same PerSourceNetBlockSize CIDR range) until the
   penalty expire.

   Repeated offenses by the same client address will accrue greater
   penalties, up to a configurable maximum. Address ranges may be
   fully exempted from penalties, e.g. to guarantee access from a set
   of trusted management addresses, using the new sshd_config(5)
   PerSourcePenaltyExemptList option.

   We hope these options will make it significantly more difficult for
   attackers to find accounts with weak/guessable passwords or exploit
   bugs in sshd(8) itself. This option is enabled by default.

 * ssh(8): allow the HostkeyAlgorithms directive to disable the
   implicit fallback from certificate host key to plain host keys.

Bugfixes
--------

 * misc: fix a number of inaccuracies in the PROTOCOL.*
   documentation files. GHPR430 GHPR487

 * all: switch to strtonum(3) for more robust integer parsing in most
   places.

 * ssh(1), sshd(8): correctly restore sigprocmask around ppoll()

 * ssh-keysign(8): stricter validation of messaging socket fd GHPR492

 * sftp(1): flush stdout after writing "sftp>" prompt when not using
   editline. GHPR480

 * sftp-server(8): fix home-directory extension implementation, it
   previously always returned the current user's home directory
   contrary to the spec. GHPR477

 * ssh-keyscan(1): do not close stdin to prevent error messages when
   stdin is read multiple times. E.g.
   echo localhost | ssh-keyscan -f - -f -

 * regression tests: fix rekey test that was testing the same KEX
   algorithm repeatedly instead of testing all of them. bz3692

 * ssh_config(5), sshd_config(5): clarify the KEXAlgorithms directive
   documentation, especially around what is supported vs available.
   bz3701.

Portability
-----------

 * sshd(8): expose SSH_AUTH_INFO_0 always to PAM auth modules
   unconditionally. The previous behaviour was to expose it only when
   particular authentication methods were in use.

 * build: fix OpenSSL ED25519 support detection. An incorrect function
   signature in configure.ac previously prevented enabling the recently
   added support for ED25519 private keys in PEM PKCS8 format.

 * ssh(1), ssh-agent(8): allow the presence of the WAYLAND_DISPLAY
   environment variable to enable SSH_ASKPASS, similarly to the X11
   DISPLAY environment variable. GHPR479

 * build: improve detection of the -fzero-call-used-regs compiler
   flag. bz3673.

 * build: relax OpenSSL version check to accept all OpenSSL 3.x
   versions.

 * sshd(8): add support for notifying systemd on server listen and
   reload, using a standalone implementation that doesn't depend on
   libsystemd. bz2641

Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
---

v2:
 - fix musl build
 - fix sshd-session packing on openssh-sshd
 - rebase on top of the CVE-2024-6387 fix sent

v3:
 - fix the ptest fail
 - update upstream status of the systemd sd-notify patch

 ...h-log-input-and-output-files-on-erro.patch |  8 ++---
 ...c-use-the-absolute-path-in-the-SSH-e.patch | 34 +++++++++++++++++++
 ...tional-support-for-systemd-sd_notify.patch | 23 +++++++------
 .../openssh/openssh/CVE-2024-6387.patch       | 27 ---------------
 ...igned-overflow-in-pointer-arithmatic.patch |  6 ++--
 .../openssh/openssh/run-ptest                 |  1 +
 .../{openssh_9.7p1.bb => openssh_9.8p1.bb}    |  9 +++--
 7 files changed, 58 insertions(+), 50 deletions(-)
 create mode 100644 meta/recipes-connectivity/openssh/openssh/0001-regress-test-exec-use-the-absolute-path-in-the-SSH-e.patch
 delete mode 100644 meta/recipes-connectivity/openssh/openssh/CVE-2024-6387.patch
 rename meta/recipes-connectivity/openssh/{openssh_9.7p1.bb => openssh_9.8p1.bb} (94%)

On Mon, 15 Jul 2024 at 20:02, Jose Quaresma via lists.openembedded.org
<quaresma.jose=gmail.com@lists.openembedded.org> wrote:
> +From: Jose Quaresma <jose.quaresma@foundries.io>
> +Date: Mon, 15 Jul 2024 18:43:08 +0100
> +Subject: [PATCH] regress/test-exec: use the absolute path in the SSH env
> +
> +The SSHAGENT_BIN was changed in [1] to SSH_BIN but
> +the last one don't use the absolute path and consequently
> +the function increase_datafile_size can loops forever.
> +
> +[1] https://github.com/openssh/openssh-portable/commit/a68f80f2511f0e0c5cef737a8284cc2dfabad818
> +
> +Upstream-Status: Pending

No Pending patches without a (good) reason please. Submit upstream
before you submit here.

Alex

On Tue, 2024-07-16 at 09:48 +0200, Alexander Kanavin via
lists.openembedded.org wrote:
> On Mon, 15 Jul 2024 at 20:02, Jose Quaresma via
> lists.openembedded.org
> <quaresma.jose=gmail.com@lists.openembedded.org> wrote:
> > +From: Jose Quaresma <jose.quaresma@foundries.io>
> > +Date: Mon, 15 Jul 2024 18:43:08 +0100
> > +Subject: [PATCH] regress/test-exec: use the absolute path in the
> > SSH env
> > +
> > +The SSHAGENT_BIN was changed in [1] to SSH_BIN but
> > +the last one don't use the absolute path and consequently
> > +the function increase_datafile_size can loops forever.
> > +
> > +[1]
> > https://github.com/openssh/openssh-portable/commit/a68f80f2511f0e0c5cef737a8284cc2dfabad818
> > +
> > +Upstream-Status: Pending
> 
> No Pending patches without a (good) reason please. Submit upstream
> before you submit here.

We need to be a little bit careful with this. I don't want to put
people off submitting upgrades to key components like this and the work
Jose has done to get this far is really helpful and appreciated.

I agree we need to cut down on the number of pending patches, so asking
people if they're able to submit is fair enough. Requiring it may be
something we can't afford to do though.

I am very worried about the height of the bar for submissions and I'm
struggling to make changes, let alone others :/.

Cheers,

Richard

Richard Purdie <richard.purdie@linuxfoundation.org> escreveu (terça,
16/07/2024 à(s) 09:53):

> On Tue, 2024-07-16 at 09:48 +0200, Alexander Kanavin via
> lists.openembedded.org wrote:
> > On Mon, 15 Jul 2024 at 20:02, Jose Quaresma via
> > lists.openembedded.org
> > <quaresma.jose=gmail.com@lists.openembedded.org> wrote:
> > > +From: Jose Quaresma <jose.quaresma@foundries.io>
> > > +Date: Mon, 15 Jul 2024 18:43:08 +0100
> > > +Subject: [PATCH] regress/test-exec: use the absolute path in the
> > > SSH env
> > > +
> > > +The SSHAGENT_BIN was changed in [1] to SSH_BIN but
> > > +the last one don't use the absolute path and consequently
> > > +the function increase_datafile_size can loops forever.
> > > +
> > > +[1]
> > >
> https://github.com/openssh/openssh-portable/commit/a68f80f2511f0e0c5cef737a8284cc2dfabad818
> > > +
> > > +Upstream-Status: Pending
> >
> > No Pending patches without a (good) reason please. Submit upstream
> > before you submit here.
>
> We need to be a little bit careful with this. I don't want to put
> people off submitting upgrades to key components like this and the work
> Jose has done to get this far is really helpful and appreciated.
>

I completely understand Alex's position and even agree with it.
I didn't do it right away because yesterday I finished late, I will send a
new v4.


>
> I agree we need to cut down on the number of pending patches, so asking
> people if they're able to submit is fair enough. Requiring it may be
> something we can't afford to do though.
>

But I also understand your position and I think this may demotivate some
users/devs.
It is important to note that when a patch enters the layer it will stay
here forever
if no one tries to submit it upstream.


>
> I am very worried about the height of the bar for submissions and I'm
> struggling to make changes, let alone others :/.
>

To be realistic, I don't see any major barriers to contributing and perhaps
the biggest ones
aren't even technical and are more corporate.

Jose


>
> Cheers,
>
> Richard
>

On Tue, 16 Jul 2024 at 11:29, Jose Quaresma <quaresma.jose@gmail.com> wrote:
>> I agree we need to cut down on the number of pending patches, so asking
>> people if they're able to submit is fair enough. Requiring it may be
>> something we can't afford to do though.
>
>
> But I also understand your position and I think this may demotivate some users/devs.
> It is important to note that when a patch enters the layer it will stay here forever
> if no one tries to submit it upstream.

Moreover, adding patches actually raises the bar for future upgrade
contributions, since such contributors will need to rebase those
patches (written by someone else who may or may not be around then)
and maybe belatedly submit them upstream. At which point people are
likely to get frustrated at their inability to rebase invasive
changes, inability to fully understand what the patch does (in order
to explain it to upstream if they have questions), or simply the
amount of work required. And they will give up and do something else.
Meanwhile there's a critical CVE in the weekly report, important fixes
for latest gcc version or some other urgent problem that would be
fixed by the upgrade. And it can't just fall to me when that happens.
So we should at least require an explanation for Pending, if not the
actual submission.

I agree that I should've used more polite, less tersely-giving-orders
language, but I'm confident Jose wouldn't get offended :)

Alex