Jose Quaresma via lists.openembedded.org <quaresma.jose=
gmail....@lists.openembedded.org> escreveu (sexta, 5/07/2024 à(s) 11:34):

>
>
> Richard Purdie <richard.pur...@linuxfoundation.org> escreveu (quinta,
> 4/07/2024 à(s) 21:27):
>
>> On Thu, 2024-07-04 at 13:46 +0100, Jose Quaresma via
>> lists.openembedded.org wrote:
>> > 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.quare...@foundries.io>
>> > ---
>> >
>> > v2:
>> >  - fix musl build
>> >  - fix sshd-session packing on openssh-sshd
>> >  - rebase on top of the CVE-2024-6387 fix sent
>>
>> Thanks for the fixes. Unfortunately I think there is still one issue
>> remaining as the openssh ptests appear to be hanging on both arm and
>> x86:
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/6600
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6778
>>
>> On a previous build run I ended up stopping them after 24h+ but I
>> wasn't sure if that was related to other issues with the update or not.
>> It now looks like it is a separate issue :(
>>
>
> I will take a look on this ptests failings.
> Thanks for reporting.
>

I will only be able to return to this next week.
I took a quick look at the ptest but I still didn't understand what was
wrong.
If anyone wants to continue this feel free.

Jose


>
> Jose
>
>
>>
>> Cheers,
>>
>> Richard
>>
>
>
> --
> Best regards,
>
> José Quaresma
>
> 
>
>

-- 
Best regards,

José Quaresma
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#201649): 
https://lists.openembedded.org/g/openembedded-core/message/201649
Mute This Topic: https://lists.openembedded.org/mt/107036805/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to