OpenSSH 8.9 release fixes sshd vulnerability

After six months of development, OpenSSH 8.9 is released, an open client and server implementation for SSH 2.0 and SFTP protocols. The new version fixes a vulnerability in sshd that could potentially allow access without authentication. The problem is caused by an integer overflow in the authentication code, but exploitation is possible only in combination with other logical errors in the code.

In its current form, the vulnerability is not exploitable when privilege splitting is enabled, as its manifestation is blocked by separate checks performed in the privilege split tracking code. Privilege sharing mode is enabled by default in 2002 starting with OpenSSH 3.2.2 and has been mandatory since the 7.5 release of OpenSSH 2017. In addition, in portable versions of OpenSSH since release 6.5 (2014), the vulnerability is blocked by compiling with the inclusion of flags to protect against integer overflows.

Other changes:

  • In the portable version of OpenSSH, sshd removed native support for password hashing using the MD5 algorithm (linking to external libraries such as libxcrypt is allowed to return).
  • ssh, sshd, ssh-add, and ssh-agent implement a subsystem to restrict forwarding and use of keys added to ssh-agent. The subsystem allows you to set rules that determine how and where keys can be used in ssh-agent. For example, to add a key that can only be used to authenticate when any user connects to the scylla.example.org host, the perseus user connects to the cetus.example.org host, and the medea user connects to the charybdis.example.org host, redirecting through an intermediate host scylla.example.org, you can use the following command: $ ssh-add -h "[email protected]" \ -h "scylla.example.org" \ -h "scylla.example.org>[email protected]\ ~/.ssh/id_ed25519
  • In ssh and sshd, the hybrid algorithm "[email protected]Β» (ECDH/x25519 + NTRU Prime), resistant to selection on quantum computers. In OpenSSH 8.9, this negotiation method was added between the ECDH and DH methods, but it is planned to be enabled by default in the next release.
  • ssh-keygen, ssh, and ssh-agent have improved handling of FIDO token keys used for device verification, including keys for biometric authentication.
  • Added "ssh-keygen -Y match-principals" command to ssh-keygen to check usernames in a file with a list of allowed names.
  • ssh-add and ssh-agent provide the ability to add PIN-protected FIDO keys to ssh-agent (a PIN request is displayed at the time of authentication).
  • ssh-keygen allows the choice of hashing algorithm (sha512 or sha256) during signing.
  • To improve performance, ssh and sshd read network data directly into the incoming packet buffer, bypassing intermediate buffering in the stack. The direct placement of the received data into the channel buffer is similarly implemented.
  • In ssh, the PubkeyAuthentication directive has expanded the list of supported parameters (yes|no|unbound|host-bound) to provide the ability to select which protocol extension to use.

In a future release, it is planned to change the default scp utility to use SFTP instead of the legacy SCP/RCP protocol. SFTP uses more predictable name handling methods and does not use shell processing of glob patterns in filenames on the other host side, which creates security problems. In particular, when using SCP and RCP, the server decides which files and directories to send to the client, and the client only checks the correctness of the returned object names, which, in the absence of proper checks on the client side, allows the server to transfer other file names that differ from those requested. The SFTP protocol does not have these problems, but does not support expansion of special paths such as "~/". To resolve this difference, in the last release of OpenSSH, a new extension to the SFTP protocol was proposed in the SFTP server implementation to expand the ~/ and ~user/ paths.

Source: opennet.ru

Add a comment