After six months of development, the release of OpenSSH 8.9, an open implementation of the client and server for SSH 2.0 and SFTP protocols, has been made available. In this new version, a vulnerability in sshd that could potentially allow access without authentication has been fixed. The problem was caused by an integer overflow in the authentication code, but exploitation is only feasible in conjunction with other logical errors in the code.
In its current state, the vulnerability is not exploitable when privilege separation mode is enabled, as its manifestation is blocked by specific checks performed in the privilege separation tracking code. Privilege separation mode has been enabled by default since 2002, starting with OpenSSH 3.2.2, and is mandatory since the release of OpenSSH 7.5, published in 2017. Furthermore, in portable versions of OpenSSH starting from the 6.5 release (2014), the vulnerability is mitigated by compiling with integer overflow protection flags.
Other changes:
- In the portable version of OpenSSH, built-in support for password hashing using the MD5 algorithm has been removed in sshd (external library linking such as with libxcrypt is allowed for backward compatibility).
- In ssh, sshd, ssh-add, and ssh-agent, a subsystem has been implemented to restrict the forwarding and usage of keys added to the ssh-agent. This subsystem allows for the specification of rules that define how and where keys can be used in ssh-agent. For example, to add a key that can only be used for authenticating any user connecting to the host scylla.example.org, user perseus to host cetus.example.org, and user medea to host charybdis.example.org with forwarding through the intermediary host scylla.example.org, the following command can be used: $ ssh-add -h "perseus@cetus.example.org" \ -h "scylla.example.org" \ -h "scylla.example.org>medea@charybdis.example.org" \ ~\/ .ssh\/id_ed25519
- In ssh and sshd, the list of KexAlgorithms, which defines the order of selection for key exchange methods, now by default includes the hybrid algorithm "sntrup761x25519-sha512@openssh.com" (ECDH/x25519 + NTRU Prime), which is resistant to brute-force attacks on quantum computers. In version OpenSSH 8.9, this negotiation method has been added between the ECDH and DH methods, but it is planned to be utilized by default in the next release.
- In ssh-keygen, ssh, and ssh-agent, the handling of keys for FIDO tokens used for device verification has been improved, including keys for biometric authentication.
- The command "ssh-keygen -Y match-principals" has been added to ssh-keygen for checking usernames in the allowed names list file.
- In ssh-add and ssh-agent, the ability to add PIN-protected FIDO keys to the ssh-agent has been provided (a PIN prompt is shown during authentication).
- In ssh-keygen, the selection of the hashing algorithm (sha512 or sha256) during signature creation has been allowed.
- In ssh and sshd, for improved performance, network data is read directly into the incoming packet buffer, bypassing intermediate buffering in the stack. Similarly, direct placement of received data into the channel buffer has been implemented.
- In ssh, the list of supported parameters (yes|no|unbound|host-bound) in the PubkeyAuthentication directive has been expanded to allow selection of the version of the protocol extension used.
In one of the following releases, it is planned to change the default utility scp to use SFTP instead of the deprecated SCP/RCP protocol. SFTP employs more predictable methods for handling names and does not use shell-based glob pattern processing of file names on the other host, which creates security issues. Specifically, with SCP and RCP, the server decides which files and directories to send to the client, while the client only verifies the correctness of the returned object names, which, in the absence of proper checks on the client side, allows for the transfer of other file names that differ from the requested ones. server The SFTP protocol does not have these issues but does not support path expansion, such as "~/". To address this difference, a new SFTP protocol extension for path expansion of ~/ and ~user/ was proposed in the previous OpenSSH release.
Source: opennet.ru
