After three months of development release , an open implementation of a client and server for working with SSH 2.0 and SFTP protocols.
The new release introduces protection against an attack on scp, allowing the server to transmit different filenames from those requested (unlike , the attack does not allow changing the user-selected directory or glob pattern). It is worth noting that in SCP, the server decides which files and directories to send to the client, while the client only verifies the correctness of the returned object names. The essence of the identified issue is that if the system call utimes fails, the file content is interpreted as file metadata.
This feature, when connecting to a server controlled by a malicious actor, can be exploited to save in the user's file system other names and content during copying using scp in configurations that cause utimes to fail (for instance, when utimes is blocked by SELinux policy or syscall filters). The likelihood of actual attacks is assessed as minimal, as in typical configurations the utimes call does not fail. Furthermore, the attack doesn’t go unnoticed—a transmission error is displayed during the scp call.
General changes:
- In sftp, the processing of the ‘-1’ argument has been discontinued, similar to ssh and scp, which was previously accepted but ignored;
- In sshd, when using IgnoreRhosts, three options are now provided: ‘yes’—ignore rhosts/shosts, ‘no’—consider rhosts/shosts, and ‘shosts-only’—allow .shosts but disallow .rhosts;
- In ssh, the handling of substitution %TOKEN in the LocalForward and RemoteForward settings, used for redirecting Unix sockets, has been ensured;
- Loading public keys from an unencrypted file with the private key is now allowed if a separate file with the public key is absent;
- If libcrypto is present on the system, ssh and sshd now use the chacha20 algorithm's implementation from this library instead of the built-in portable implementation, which lags in performance;
- The capability to dump the contents of a binary list of revoked certificates when executing the ‘ssh-keygen -lQf /path’ command has been implemented;
- The portable version has implemented the identification of systems in which signals with the SA_RESTART option interrupt the operation of select;
- Assembly issues in HP/UX and AIX systems have been resolved;
- Problems with the seccomp sandbox assembly in certain Linux configurations have been fixed;
- Improved detection of the libfido2 library and resolved assembly issues with the ‘--with-security-key-builtin’ option.
OpenSSH developers have once again warned about the upcoming transition to deprecation of algorithms that use SHA-1 hashes due to efficiency of collision attacks with a defined prefix (the cost of finding a collision is estimated at approximately $45,000). In an upcoming release, the default option to use the ‘ssh-rsa’ public key digital signature algorithm will be disabled, which is mentioned in the original RFC for the SSH protocol and remains widely used in practice (to check the use of ssh-rsa in your systems, try connecting via ssh with the ‘-oHostKeyAlgorithms=-ssh-rsa’ option).
To smooth the transition to new algorithms in OpenSSH, the UpdateHostKeys setting will be enabled by default in one of the next releases, allowing clients to automatically switch to more secure algorithms. Recommended algorithms for migration include rsa-sha2-256/512 based on RFC8332 RSA SHA-2 (supported since OpenSSH 7.2 and used by default), ssh-ed25519 (supported since OpenSSH 6.5), and ecdsa-sha2-nistp256/384/521 based on RFC5656 ECDSA (supported since OpenSSH 5.7).
Starting from the last release, ‘ssh-rsa’ and ‘diffie-hellman-group14-sha1’ have been removed from the list of CASignatureAlgorithms, which defines the algorithms permissible for the digital signatures of new certificates, as the use of SHA-1 in certificates poses additional risks because an attacker has unlimited time to find a collision for an existing certificate, while the time for attacks on host keys is limited by the connection timeout (LoginGraceTime).
Source: opennet.ru
