OpenSSH

[Brother]

The developers of the OpenSSH project have presented a plan to end support for keys based on the DSA algorithm. By modern standards, DSA keys do not provide the proper level of security, since they use a private key size of only 160 bits and a SHA1 hash, which in terms of security level corresponds to approximately an 80-bit symmetric key.

By default, the use of DSA keys was discontinued in 2015, but DSA support is left as an option, since this algorithm is the only one required for implementation in the SSHv2 protocol. This requirement was added because at the time of the creation and approval of the SSHv2 protocol, all alternative algorithms were subject to patents. Since then, the situation has changed, the patents associated with RSA have expired, the ECDSA algorithm has been added, which is significantly superior to DSA in performance and security, as well as EdDSA, which is safer and faster than ECDSA. The only factor in continuing DSA support was maintaining compatibility with legacy devices.

Having assessed the situation in the current realities, the OpenSSH developers came to the conclusion that the costs of continuing to maintain the insecure DSA algorithm are not justified and its removal will encourage the cessation of DSA support in other SSH implementations and cryptographic libraries. The April release of OpenSSH plans to retain the DSA build, but provide the ability to disable DSA at compile time. In the June release of OpenSSH, DSA will be disabled by default when building, and the DSA implementation will be removed from the codebase in early 2025.

Users who require client-side DSA support will be able to use alternative builds of older versions of OpenSSH, such as the Debian-supplied package "openssh-client-ssh1", built on top of OpenSSH 7.5 and designed for connecting to SSH servers using the SSHv1 protocol, which was discontinued in OpenSSH 7.6 six years ago.

 

[Tomcat]

The release of OpenSSH 9.7, an open client and server implementation for SSH 2.0 and SFTP protocols, has been published. The proposed version has started making changes that precede the future termination of support for keys based on the DSA algorithm. OpenSSH 9.7 provides an option to disable DSA at compile time, but the default build with DSA support is still preserved. In the next release, scheduled for June, the build mode will be changed to disable DSA by default, and in early 2025, the DSA implementation will be removed from the codebase.

By default, the use of DSA keys was discontinued back in 2015, but the code for DSA support was compiled by default and allowed you to return the DSA through the settings. It is noteworthy that the DSA algorithm is the only mandatory implementation in the SSHv2 protocol. This requirement was added because at the time of creation and approval of the SSHv2 protocol, all alternative algorithms were subject to patents. Since then, the situation has changed, patents related to RSA have been discontinued, the ECDSA algorithm has been added, which is significantly ahead of DSA in terms of performance and security, as well as EdDSA, which is safer and faster than ECDSA.

The only factor in continuing to support DSA was maintaining compatibility with legacy devices. In the current reality, the cost of continuing to maintain the insecure DSA algorithm is not justified, and its removal will encourage the termination of DSA support in other SSH implementations and cryptographic libraries.

In addition to changes related to DSA, the new release introduces a new type of timeouts in ssh and sshd, which can be enabled by specifying the "global" value in the ChannelTimeout directive. In the new mode, OpenSSH monitors all open channels and closes them at once if there was no traffic in all of them for the specified period of time. For example, when both SSH session and x11 redirection channels are open to the host at the same time, the new mode allows you to close both channels at once if they are inactive, instead of tracking timeouts for each channel separately. Among the changes, there is also a significant improvement in compatibility testing with the PuTTY project.

===

The OpenSSH codebase has built-in protection against automated password guessing attacks, in which bots try to guess the user's password by sorting through various typical combinations. To block such attacks, the persourcepenalities parameter has been added to the sshd_config configuration file, which allows you to determine the blocking threshold that is triggered when a large number of failed connection attempts are made from a single IP address. The new security mechanism will be included in the next release of OpenSSH and will be enabled by default in OpenBSD 7.6.

When protection is enabled, the sshd process starts monitoring the termination status of child processes, identifying situations when authentication failed or when the process was aborted due to a failure. A high rate of authentication failures indicates attempts to select passwords, and a crash may indicate attempts to exploit vulnerabilities in sshd.

The persourcepenalities parameter sets the minimum threshold for abnormal events, after which the IP address for which suspicious activity is recorded will be blocked. Using the PerSourceNetBlockSize parameter, you can additionally define a subnet mask to block the entire subnet to which the problem IP belongs.

To disable blocking for individual subnets, the PerSourcePenaltyExemptList parameter is suggested, which can be useful in situations that lead to false positives, for example, when the SSH server is accessed from a large network, where requests from different users come from the same IP address due to the use of an address translator or proxy.

 

[Carding Forum]

A vulnerability in OpenSSH that allows remote code execution with root privileges on servers running Glibc.

Qualys has identified a critical vulnerability (CVE-2024-6387) in OpenSSH that allows remote code execution with root privileges without passing authentication. The vulnerability, which was codenamed regreSSHion, has been present since OpenSSH version 8.5 on systems with the Glibc standard library.

The possibility of performing an attack was demonstrated on a 32-bit system with Glibc with ASLR (address space randomization) protection enabled. For a successful attack in the laboratory, it took 6-8 hours, during which connections were continuously established with the server at the maximum allowed intensity in the sshd configuration. Performing the attack is simplified and requires less time on systems without ASLR or on distributions that use modified OpenSSH, which disables re-randomization of ASLR for each connection.

The possibility of an attack on 64-bit systems is also possible, but a working exploit for such systems is not yet ready. It is assumed that an attack on 64-bit systems will take much longer, but no more than a week. OpenSSH in OpenBSD is not affected by the problem, but in other systems based on standard libraries other than Glibc, it is theoretically possible to adapt the method to perform an attack (this issue has not yet been studied in Qualys).

The vulnerability is fixed in the OpenSSH 9.8 release (patch) published today. As a workaround for blocking the vulnerability in sshd_config, you can set the parameter "LoginGraceTime=0".

The vulnerability occurred as a result of a regressive change that was included in the OpenSSH 8.5 release and leads to a race condition in the signal processing code in sshd. The regression led to the termination of protection against the old vulnerability CVE-2006-5051, which was manifested before the OpenSSH 4.4 version (2006) and was of a theoretical nature. During the development of OpenSSH 8.5, the "#ifdef DO_LOG_SAFE_IN_SIGHAND " block was removed by mistake from the sigdie () function, which is directly called from the SIGALRM handler.

The SIGALRM handler is called asynchronously in sshd if the client has not authenticated within the time limit of the connection timeout (LoginGraceTime, default 120 seconds). The attack is based on the fact that the signal handler calls functions that are not safe for asynchronous signal processing, such as syslog().

-----

The release of OpenSSH 9.8, an open client and server implementation for SSH 2.0 and SFTP protocols, has been published. In addition to fixing a separately announced critical vulnerability (CVE-2024-6387), which allows remote code execution with root rights at the pre-authentication stage, the new version fixes another less dangerous vulnerability and offers several significant changes aimed at improving security.

The second vulnerability allows you to bypass the protection added in version OpenSSH 9.5 against attacks on third-party channels that analyze delays between keystrokes on the keyboard to recreate input. The vulnerability allows you to distinguish packets that create background activity through the simulation of fake keystrokes from packets sent when real keys are pressed, which reduces the effectiveness of the mechanism for hiding interactive input features in ssh traffic. Data on keystrokes allows you to use attacks that recreate input based on the analysis of delays between keystrokes when typing, which depend on the location of keys on the keyboard (for example, the reaction when entering the letter " F "is faster than when entering" Q "or" X", since pressing requires less finger movements).

In addition, it turned out that the implemented algorithm for sending packets with real and fictitious clicks reduced the reliability of another method of protecting against attacks via third-party channels. Starting with the release of OpenSSH 2.9.9, the server sent dummy push packets for console input in echo-off mode, which is used, for example, when entering passwords in su or sudo. The new logic for sending dummy packets allowed passive traffic analysis to select packets with real clicks in echo-off mode for their separate analysis. At the same time, the accuracy of information about the time of clicks is limited, since after dialing, packets are sent not immediately, but at fixed intervals (by default, 20 ms).

Other changes in OpenSSH 9.8:

* At the build stage, support for digital signatures based on the DSA algorithm is disabled by default. In early 2025, the DSA implementation will be removed from the codebase. The reason for deletion is the level of protection in the DSA that does not meet modern requirements. The cost of continuing to maintain the insecure DSA algorithm is not justified, and its removal will encourage the termination of DSA support in other SSH implementations and cryptographic libraries.

• For additional protection against exploiting vulnerabilities that require a large number of connections to the sshd, a new security mode has been implemented and enabled by default, which also helps to block automated password matching attacks, during which bots try to guess the user's password by going through various typical combinations. Protection is implemented by blocking IP addresses that record a large number of failed connection attempts . sshd monitors the termination status of child processes, identifying situations when authentication failed or when the process was aborted due to a failure, and when a certain threshold is exceeded, it starts blocking requests from problematic IP addresses or subnets. The persourcepenalities, PerSourceNetBlockSize, and PerSourcePenaltyExemptList parameters are used to configure the lock threshold, subnet mask, and exception list.

* Split sshd into several separate executable files. The sshd-session process is allocated from sshd, which performs tasks related to session processing. The sshd process retains the functions responsible for accepting network connections, checking configuration, loading host keys, and managing running processes in accordance with the MaxStartups parameter. Thus, the sshd executable file now contains the minimum functionality required to accept a new network connection and run sshd-session to process the session.

• The text of some error messages recorded in the log has changed. In particular, a number of messages are now sent on behalf of the "sshd-session" process, rather than "sshd".

* The ssh-keyscan utility now outputs information about the protocol version and hostname to the standard stream, instead of STDERR. To disable the output, the "-q " option is suggested.

* SSH implements the ability to disable the rollback from using the host key certificate to using plain host keys via the HostKeyAlgorithms directive.

* In the portable version of sshd, the argv[0] value is no longer used to determine the name of the PAM service. To set the name of the PAM service, a new directive "PAMServiceName" has been added to sshd_config, which is set to "sshd"by default.

* In the portable version of sshd, automatically generated files are saved (configure script, config.h.in etc.) in the Git branch with releases (for example, V_9_8), which made it possible to synchronize the composition of digitally signed tar archives and branches in Git.

* In the portable version of ssh and ssh-agent, the SSH_ASKPASS mode is set when the WAYLAND_DISPLAY environment variable is present, similar to how it was done for X11 when the DISPLAY environment variable is present.

* The portable version of sshd adds support for sending notifications to systemd when a listening network socket is created or restarted, using separate code that does not access the libsystemd library.

 

[Carding Forum]

In the process of studying a critical vulnerability identified last week in OpenSSH, another similar vulnerability (CVE-2024-6409) was discovered, which allows remote code execution without passing authentication. The new vulnerability is not as dangerous as the previous one, as it manifests itself after resetting privileges in the child process running by the SSH server. The vulnerability is present in openssh packages from the Red Hat Enterprise Linux 9 distribution, based on the OpenSSH 8.7 release published in 2021. The problem also affects packages for Fedora Linux 36 and 37, based on the OpenSSH 8.7 and 8.8 releases.

The vulnerability is essentially similar to the previous issue and is also caused by a race condition in the SIGALRM interrupt handler, which occurs due to the execution of functions that are not designed to be called asynchronously from signal handlers. The handler is triggered when the timeout specified in the LoginGraceTime parameter occurs and interrupts the current code execution. Using non-asynchronous interrupt handler functions that use dynamic memory allocation, such as syslog (), can cause internal malloc structures to be corrupted when SIGALRM is triggered during the execution of certain code.

The new vulnerability differs in that the race condition occurs due to the call of the cleanup_exit() function in the grace_alarm_handler () signal handler. In the main OpenSSH codebase, this function can be used in asynchronously executed code, but in packages for RHEL 9 and Fedora, an additional patch was applied that adds a function call for generating audit events to cleanup_exit (), which is not intended for use in signal handlers.

This patch was used in RHEL 9 and derived distributions in packages based on OpenSSH 8. 7p1. In current Fedora releases, the problem does not appear, since starting with Fedora 38, the distribution switched to a newer version of OpenSSH without changing cleanup_exit(). Unlike the previous vulnerability, a workaround based on the use of the "-e" option in sshd, which disables log output via syslog, is not suitable for blocking a new problem. However, to block the vulnerability in sshd_config, you can set the parameter "LoginGraceTime=0".

 

[Friend]

OpenSSH 9.9 released with support for ML-KEM post-quantum encryption algorithm.

OpenSSH 9.9, an open client and server implementation for SSH 2.0 and SFTP, has been released.

Major changes:

• In ssh and sshd, support has been added for the hybrid key exchange algorithm "mlkem768x25519-sha256", which is a combination of X25519 ECDH and the ML-KEM (CRYSTALS-Kyber) algorithm, recently standardized by the US National Institute of Standards and Technology (NIST). ML-KEM uses cryptography methods based on solving lattice theory problems, the solution time of which does not differ on conventional and quantum computers.

• The "RefuseConnection" keyword sshd_config added to the configuration file, which will cause sshd to terminate connections after the first authentication attempt. A class "refuseconnection" has been added to the PerSourcePenalties directive, which is applied when the connection is terminated after the "RefuseConnection" is fired.

• The ssh client no longer supports data compression at the pre-authentication stage, which significantly increases the attack surface on SSH servers and creates the risk of using indirect methods to analyze the information sent during the authentication process. In the sshd server, compression before authentication was disabled earlier.

• In ssh and sshd, when parsing the arguments of the "Match" directive, they use shell-like rules for dealing with strings enclosed in quotation marks, supporting nested framing and escaping with the "".

• In the ssh_config configuration file, the "Include" directive supports environment variables and "%" substitutions, the same as in the "Match Exec" directive.

• In sshd_config, the "invalid-user" option has been added to the Match directive, which is triggered when trying to log in with an incorrect username.

• Faster implementation of the "Streamlined NTRUPrime" algorithm is used in ssh and sshd. For the Streamlined NTRUPrime/X25519 hybrid key exchange algorithm, the ability to use the name "sntrup761x25519-sha512" has been added, in addition to the SSH-specific name "sntrup761x25519-sha512@openssh.com".

• Added protection against private key settling in core files that works in OpenBSD, Linux and FreeBSD.

• Key handling has been switched to using the EVP_PKEY API provided by the libcrypto library.

• Added a random change in the connection timeout (LoginGraceTime) within 4 seconds to sshd to make it more difficult to determine the timeout expiration.

• Resolved build issues with the Musl library.