OpenSSH Flaws Expose Remote Code Execution Risks

Recent OpenSSH vulnerabilities could allow unauthenticated remote code execution with root privileges on glibc-based Linux systems, posing significant security
Subscribe to Sonar
Get the best and latest safety tips delivered to your inbox each month.
SHare this
In this article
We've explored vulnerabilities in OpenSSH that could let attackers compromise system security. Key weaknesses, like the signal handling issue, could be exploited for remote code execution on certain systems. We've also outlined essential steps for users and admins to mitigate the risks.

About OpenSSH

OpenSSH is the premier connectivity tool for remote login with the SSH protocol. It encrypts all traffic to eliminate eavesdropping, connection hijacking, and other attacks. In addition, OpenSSH provides a large suite of secure tunnelling capabilities, several authentication methods, and sophisticated configuration options. OpenSSH is widely used on Unix-like systems, including macOS and Linux, and it supports various encryption technologies and enforces robust access controls.

Even though some recent security issues were found, OpenSSH continues to be a reliable and essential tool for keeping online communications private and secure around the world.

Executive Summary

On July 1, 2024, a security regression (CVE-2006-5051) known as RegreSSHion, identified by CVE-2024-6387, was discovered in OpenSSH's server (sshd) on glibc-based Linux systems. This regression involves a race condition that causes sshd to handle certain signals unsafely. An unauthenticated remote attacker could exploit this vulnerability by failing to authenticate within a set time period.

This vulnerability can be exploited remotely on glibc-based Linux systems due to syslog() calling async-signal-unsafe functions like malloc() and free(), leading to unauthenticated remote code execution as root. This occurs because sshd's privileged code is not sandboxed and runs with full privileges. OpenBSD is not vulnerable because its signal alarm (SIGALRM) handler uses syslog_r(), an async-signal-safe version of syslog().

The OpenSSH team said that exploiting this vulnerability typically requires 6-8 hours of continuous connections under lab conditions, pushing the server to its maximum capacity. However, these attacks will likely be further refined and improved upon.

Following the discovery of RegreSSHion, another related vulnerability emerged. This second flaw builds on the initial weakness, presenting additional risks and challenges. This new vulnerability, tracked as CVE-2024-6409 represents a separate vulnerability from CVE-2024-6387. It involves code execution within the privsep child process which runs with reduced privileges compared to the parent server process. This vulnerability was found by security researcher Alexander Peslyak, known as Solar Designer, during a review of CVE-2024-6387 and specifically affects versions 8.7p1 and 8.8p1 included in Red Hat Enterprise Linux 9.

Affected OpenSSH versions

Mitigation

To mitigate CVE-2024-6387, it is recommended to set LoginGraceTime to 0 in /etc/ssh/sshd_config. This adjustment, while potentially making sshd vulnerable to a denial-of-service attack (specifically the exhaustion of all MaxStartups connections), effectively secures against CVE-2024-6387.

Updating OpenSSH to a version higher than 8.8p1 is recommended to mitigate CVE-2024-6409 effectively.

Conclusion

For everyday users concerned about online security, the recent vulnerabilities in OpenSSH may seem intimidating, but understanding the basics can help mitigate risks. Ensure your system is regularly updated to the latest software versions, especially for critical tools like OpenSSH. While these vulnerabilities are complex, following basic security practices, staying informed, and implementing simple yet effective security measures, can significantly enhance your online safety and protect against potential exploits.