On Mon, Dec 18, 2023 at 08:33:09AM -0700, Damien Miller wrote: > OpenSSH 9.6 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 > Major bug issue. I tell openssh 9.6 to look into my /jusr/local/ for the correct openssl but it is instead looking at /usr in for the library! This is a show stoppper. Please fix! Running FreeBSD 14.0 all patched up! > Changes since OpenSSH 9.5 > ========================= > > This release contains a number of security fixes, some small features > and bugfixes. > > Security > ======== > > This release contains fixes for a newly-discovered weakness in the > SSH transport protocol, a logic error relating to constrained PKCS#11 > keys in ssh-agent(1) and countermeasures for programs that invoke > ssh(1) with user or hostnames containing invalid characters. > > * ssh(1), sshd(8): implement protocol extensions to thwart the > so-called "Terrapin attack" discovered by Fabian B??umer, Marcus > Brinkmann and J??rg Schwenk. This attack allows a MITM to effect a > limited break of the integrity of the early encrypted SSH transport > protocol by sending extra messages prior to the commencement of > encryption, and deleting an equal number of consecutive messages > immediately after encryption starts. A peer SSH client/server > would not be able to detect that messages were deleted. > > While cryptographically novel, the security impact of this attack > is fortunately very limited as it only allows deletion of > consecutive messages, and deleting most messages at this stage of > the protocol prevents user user authentication from proceeding and > results in a stuck connection. > > The most serious identified impact is that it lets a MITM to > delete the SSH2_MSG_EXT_INFO message sent before authentication > starts, allowing the attacker to disable a subset of the keystroke > timing obfuscation features introduced in OpenSSH 9.5. There is no > other discernable impact to session secrecy or session integrity. > > OpenSSH 9.6 addresses this protocol weakness through a new "strict > KEX" protocol extension that will be automatically enabled when > both the client and server support it. This extension makes > two changes to the SSH transport protocol to improve the integrity > of the initial key exchange. > > Firstly, it requires endpoints to terminate the connection if any > unnecessary or unexpected message is received during key exchange > (including messages that were previously legal but not strictly > required like SSH2_MSG_DEBUG). This removes most malleability from > the early protocol. > > Secondly, it resets the Message Authentication Code counter at the > conclusion of each key exchange, preventing previously inserted > messages from being able to make persistent changes to the > sequence number across completion of a key exchange. Either of > these changes should be sufficient to thwart the Terrapin Attack. > > More details of these changes are in the PROTOCOL file in the > OpenSSH source distribition. > > * ssh-agent(1): when adding PKCS#11-hosted private keys while > specifying destination constraints, if the PKCS#11 token returned > multiple keys then only the first key had the constraints applied. > Use of regular private keys, FIDO tokens and unconstrained keys > are unaffected. > > * ssh(1): if an invalid user or hostname that contained shell > metacharacters was passed to ssh(1), and a ProxyCommand, > LocalCommand directive or "match exec" predicate referenced the > user or hostname via %u, %h or similar expansion token, then > an attacker who could supply arbitrary user/hostnames to ssh(1) > could potentially perform command injection depending on what > quoting was present in the user-supplied ssh_config(5) directive. > > This situation could arise in the case of git submodules, where > a repository could contain a submodule with shell characters in > its user/hostname. Git does not ban shell metacharacters in user > or host names when checking out repositories from untrusted > sources. > > Although we believe it is the user's responsibility to ensure > validity of arguments passed to ssh(1), especially across a > security boundary such as the git example above, OpenSSH 9.6 now > bans most shell metacharacters from user and hostnames supplied > via the command-line. This countermeasure is not guaranteed to be > effective in all situations, as it is infeasible for ssh(1) to > universally filter shell metacharacters potentially relevant to > user-supplied commands. > > User/hostnames provided via ssh_config(5) are not subject to these > restrictions, allowing configurations that use strange names to > continue to be used, under the assumption that the user knows what > they are doing in their own configuration files. > > Potentially incompatible changes > -------------------------------- > > * ssh(1), sshd(8): the RFC4254 connection/channels protocol provides > a TCP-like window mechanism that limits the amount of data that > can be sent without acceptance from the peer. In cases where this > limit was exceeded by a non-conforming peer SSH implementation, > ssh(1)/sshd(8) previously discarded the extra data. From OpenSSH > 9.6, ssh(1)/sshd(8) will now terminate the connection if a peer > exceeds the window limit by more than a small grace factor. This > change should have no effect of SSH implementations that follow > the specification. > > New features > ------------ > > * ssh(1): add a %j token that expands to the configured ProxyJump > hostname (or the empty string if this option is not being used) > that can be used in a number of ssh_config(5) keywords. bz3610 > > * ssh(1): add ChannelTimeout support to the client, mirroring the > same option in the server and allowing ssh(1) to terminate > quiescent channels. > > * ssh(1), sshd(8), ssh-add(1), ssh-keygen(1): add support for > reading ED25519 private keys in PEM PKCS8 format. Previously > only the OpenSSH private key format was supported. > > * ssh(1), sshd(8): introduce a protocol extension to allow > renegotiation of acceptable signature algorithms for public key > authentication after the server has learned the username being > used for authentication. This allows varying sshd_config(5) > PubkeyAcceptedAlgorithms in a "Match user" block. > > * ssh-add(1), ssh-agent(1): add an agent protocol extension to allow > specifying certificates when loading PKCS#11 keys. This allows the > use of certificates backed by PKCS#11 private keys in all OpenSSH > tools that support ssh-agent(1). Previously only ssh(1) supported > this use-case. > > Bugfixes > -------- > > * ssh(1): when deciding whether to enable the keystroke timing > obfuscation, enable it only if a channel with a TTY is active. > > * ssh(1): switch mainloop from poll(3) to ppoll(3) and mask signals > before checking flags set in signal handler. Avoids potential > race condition between signaling ssh to exit and polling. bz3531 > > * ssh(1): when connecting to a destination with both the > AddressFamily and CanonicalizeHostname directives in use, > the AddressFamily directive could be ignored. bz5326 > > * sftp(1): correct handling of the limits@xxxxxxxxxxx option when > the server returned an unexpected message. > > * A number of fixes to the PuTTY and Dropbear regress/integration > tests. > > * ssh(1): release GSS OIDs only at end of authentication, avoiding > unnecessary init/cleanup cycles. bz2982 > > * ssh_config(5): mention "none" is a valid argument to IdentityFile > in the manual. bz3080 > > * scp(1): improved debugging for paths from the server rejected for > not matching the client's glob(3) pattern in old SCP/RCP protocol > mode. > > * ssh-agent(1): refuse signing operations on destination-constrained > keys if a previous session-bind operation has failed. This may > prevent a fail-open situation in future if a user uses a mismatched > ssh(1) client and ssh-agent(1) where the client supports a key type > that the agent does not support. > > Portability > ----------- > > * Better identify unsupported and unstable compiler flags, such as > -fzero-call-used-regs which has been unstable across a several > clang releases. > > * A number of fixes to regression test reliability and log > collection. > > * Update the OpenSSL dependency in the RPM specification. > > * sshd(8): for OpenSolaris systems that support privilege limitation > via the getpflags() interface, prefer using the newer PRIV_XPOLICY > to PRIV_LIMIT. bz2833 > > Checksums: > ========== > > - SHA1 (openssh-9.6.tar.gz) = a6d4cb69811e879e2f158c2e597fd9f444b26506 > - SHA256 (openssh-9.6.tar.gz) = nejPUhSnG1R1sOmIBi/t+HMNvsRqfN/DJgjwIU2tvqg= > > - SHA1 (openssh-9.6p1.tar.gz) = de300d09ec79fdbf37de4e6672cce4161439f2c3 > - SHA256 (openssh-9.6p1.tar.gz) = kQIRwHJVqMWtZUORtA7lmABxDdgRndU2LeCThap6d3w= > > 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@xxxxxxxxxxx > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Member - Liberal International This is doctor@xxxxx Ici doctor@xxxxx Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Merry Christmas 2023 and Happy New year 2024 Beware https://mindspring.com _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
