During the investigation of the critical vulnerability discovered in OpenSSH last week, a similar vulnerability (CVE-2024-6409) has been found, allowing remote code execution without authentication. The new vulnerability is not as severe as the previous one, as it manifests after privilege escalation in a child process spawned by the SSH server. This vulnerability exists in Red Hat Enterprise Linux 9 packages for openssh, based on the OpenSSH 8.7 release published in 2021. The issue also affects packages for Fedora Linux 36 and 37, based on OpenSSH releases 8.7 and 8.8.
Essentially, the vulnerability is similar to the previous issue and is also caused by a race condition in the SIGALRM interrupt handler, arising from the execution of functions not designed to be called in an asynchronous mode from signal handlers. The handler triggers upon a timeout defined by the LoginGraceTime parameter and interrupts the current code execution. Using functions in the interrupt handler that are not designed for asynchronous execution, particularly those involving dynamic memory allocation like syslog(), can lead to corruption of malloc's internal structures when SIGALRM is triggered during specific code execution.
The new vulnerability differs in that the race condition arises due to the invocation of the cleanup_exit() function in the grace_alarm_handler() signal handler. In the main OpenSSH codebase, this function may be used in asynchronously executed code, but in the RHEL 9 and Fedora packages, an additional patch was applied that adds a call in cleanup_exit() for generating audit events, meant for use in signal handlers.
This patch was used in RHEL 9 and its derivative distributions in packages based on OpenSSH 8.7p1. In current Fedora releases, the issue does not manifest, as starting with Fedora 38 the distribution has switched to a newer version of OpenSSH without modifying cleanup_exit(). Unlike the previous vulnerability, a workaround for the new problem based on using the 'sshd -e' option to disable logging via syslog is not suitable. However, to mitigate the vulnerability, the 'LoginGraceTime=0' parameter can be set in sshd_config.
Source: opennet.ru
