|
|
Log in / Subscribe / Register

OpenSSH 9.3 released

OpenSSH 9.3 has been released. It includes a couple of security fixes, as well as adding an option for hash-algorithm selection to ssh-keygen and an option that allows configuration checking without actually loading any private keys.


From:  Damien Miller <djm-AT-cvs.openbsd.org>
To:  lwn-AT-lwn.net
Subject:  Announce: OpenSSH 9.3 released
Date:  Wed, 15 Mar 2023 17:18:38 -0600
Message-ID:  <488129246b9715e6@cvs.openbsd.org>

OpenSSH 9.3 has just been released. It will be available from the
mirrors listed at https://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol 2.0 implementation and
includes sftp client and server support.

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
https://www.openssh.com/donations.html

Changes since OpenSSH 9.2
=========================

This release fixes a number of security bugs.

Security
========

This release contains fixes for a security problem and a memory
safety problem. The memory safety problem is not believed to be
exploitable, but we report most network-reachable memory faults as
security bugs.

 * ssh-add(1): when adding smartcard keys to ssh-agent(1) with the
   per-hop desination constraints (ssh-add -h ...) added in OpenSSH
   8.9, a logic error prevented the constraints from being
   communicated to the agent. This resulted in the keys being added
   without constraints. The common cases of non-smartcard keys and
   keys without destination constraints are unaffected. This problem
   was reported by Luci Stanescu.

 * ssh(1): Portable OpenSSH provides an implementation of the
   getrrsetbyname(3) function if the standard library does not
   provide it, for use by the VerifyHostKeyDNS feature. A
   specifically crafted DNS response could cause this function to
   perform an out-of-bounds read of adjacent stack data, but this
   condition does not appear to be exploitable beyond denial-of-
   service to the ssh(1) client.

   The getrrsetbyname(3) replacement is only included if the system's
   standard library lacks this function and portable OpenSSH was not
   compiled with the ldns library (--with-ldns). getrrsetbyname(3) is
   only invoked if using VerifyHostKeyDNS to fetch SSHFP records. This
   problem was found by the Coverity static analyzer.

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

 * ssh-keygen(1), ssh-keyscan(1): accept -Ohashalg=sha1|sha256 when
   outputting SSHFP fingerprints to allow algorithm selection. bz3493
    
 * sshd(8): add a `sshd -G` option that parses and prints the
   effective configuration without attempting to load private keys
   and perform other checks. This allows usage of the option before
   keys have been generated and for configuration evaluation and
   verification by unprivileged users.

Bugfixes
--------

 * scp(1), sftp(1): fix progressmeter corruption on wide displays;
   bz3534

 * ssh-add(1), ssh-keygen(1): use RSA/SHA256 when testing usability
   of private keys as some systems are starting to disable RSA/SHA1
   in libcrypto.

 * sftp-server(8): fix a memory leak. GHPR363

 * ssh(1), sshd(8), ssh-keyscan(1): remove vestigal protocol
   compatibility code and simplify what's left.

 * Fix a number of low-impact Coverity static analysis findings.
   These include several reported via bz2687

 * ssh_config(5), sshd_config(5): mention that some options are not
   first-match-wins.

 * Rework logging for the regression tests. Regression tests will now
   capture separate logs for each ssh and sshd invocation in a test.

 * ssh(1): make `ssh -Q CASignatureAlgorithms` work as the manpage
   says it should; bz3532.

 * ssh(1): ensure that there is a terminating newline when adding a
   new entry to known_hosts; bz3529

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

 * sshd(8): harden Linux seccomp sandbox. Move to an allowlist of
   mmap(2), madvise(2) and futex(2) flags, removing some concerning
   kernel attack surface.

 * sshd(8): improve Linux seccomp-bpf sandbox for older systems;
   bz3537

Checksums:
==========

- SHA1 (openssh-9.3.tar.gz) = 5f9d2f73ddfe94f3f0a78bdf46704b6ad7b66ec7
- SHA256 (openssh-9.3.tar.gz) = eRcXkFZByz70DUBUcyIdvU0pVxP2X280FrmV8pyUdrk=

- SHA1 (openssh-9.3p1.tar.gz) = 610959871bf8d6baafc3525811948f85b5dd84ab
- SHA256 (openssh-9.3p1.tar.gz) = 6bq6dwGnalHz2Fpiw4OjydzZf6kAuFm8fbEUwYaK+Kg=

Please note that the SHA256 signatures are base64 encoded and not
hexadecimal (which is the default for most checksum tools). The PGP
key used to sign the releases is available from the mirror sites:
https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc

Reporting Bugs:
===============

- Please read https://www.openssh.com/report.html
  Security bugs should be reported directly to openssh@openssh.com


to post comments

Post-quantum cryptography

Posted Mar 16, 2023 15:59 UTC (Thu) by proski (guest, #104) [Link] (3 responses)

What's the status of post-quantum cryptography in OpenSSH? As I understand, OpenSSH has code to support XMSS keys, but that code is disabled by default. Also, the key exchange protocol needs to be post-quantum. I saw some announcements to that effect a while ago, but I'm not sure it's actually supported by default.

Post-quantum cryptography

Posted Mar 16, 2023 17:38 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (2 responses)

My understanding is that OpenSSH 9.x has sntrup761x25519-sha512@tinyssh.org enabled by default.

So if your server and clients are both new enough, you get the PQ key exchange. Since there is no reason to believe anybody has or is likely soon to obtain a working Quantum Computer powerful enough to attack real world cryptography, there is no reason to protect anything beyond the KEX.

[Protecting the KEX matters because you can keep encrypted transcripts and decrypt them later once you have a suitable attack on the KEX. If you never obtain such an attack, most other breaks are worthless to you for these transcripts]

sntrup761x25519-sha512@tinyssh.org is a hybrid approach, if it turns out the NTRU algorithm is busted, you're not really worse off than if you'd stayed with a conventional KEX algorithm except that you wasted some CPU cycles and bandwidth.

Post-quantum cryptography

Posted Mar 16, 2023 21:38 UTC (Thu) by proski (guest, #104) [Link]

Thank you, that makes sense. All I need now is to upgrade OpenSSH on older systems.

Post-quantum cryptography

Posted Mar 17, 2023 14:53 UTC (Fri) by NightMonkey (subscriber, #23051) [Link]

Thank you for this. I'm certainly interested in understanding better the effect of quantum computing on encryption - both theoretical and practical.


Copyright © 2023, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds