Tech: Remote Code Execution in OpenSSH: A Wake-Up Call for Linux Systems

In a startling revelation, Qualys has uncovered a critical Remote Code Execution (RCE) vulnerability in OpenSSH’s server (sshd) on glibc-based Linux systems. This security flaw, identified as CVE-2024-6387, allows unauthenticated attackers to execute code remotely as root, posing a significant risk to servers worldwide.

The Unexpected Flaw in OpenSSH

OpenSSH is renowned for its robust security, making this vulnerability all the more surprising. The issue lies in a race condition within the sshd signal handler, triggered when a client fails to authenticate within the designated LoginGraceTime.

History Repeats Itself

This vulnerability isn’t new; it’s a re-emergence of an older flaw (CVE-2006-5051) that resurfaced due to a change in OpenSSH version 8.5p1 back in October 2020. This change inadvertently reintroduced the vulnerability by removing a crucial safeguard.

Which Versions Are Affected?

Older than 4.4p1: Vulnerable unless patched against older issues CVE-2006-5051 or CVE-2008-4109.
4.4p1 to 8.5p1: Safe due to the safeguard in place.
8.5p1 to 9.8p1: Vulnerable again due to the removal of the safeguard.

How the Exploit Works

Qualys researchers detailed the complex steps required to exploit this vulnerability:

Older Versions (OpenSSH 3.4p1 and 4.2p1): The exploit involves manipulating free() calls in sshd’s public-key parsing or PAM structures. With about 10,000 attempts, an attacker could achieve success, taking from a few days to a week.
Recent Version (OpenSSH 9.2p1): This exploit targets malloc() calls within the SIGALRM handler’s syslog() function. It takes approximately 6-8 hours due to modern protections like Address Space Layout Randomization (ASLR).

The Challenges

The exploit hinges on three main challenges:

Theory: Identifying a code path that, when interrupted at the right moment, leaves sshd in an exploitable state.
Practice: Maximizing the likelihood of hitting this code path during an interrupt.
Timing: Fine-tuning the attack to coincide perfectly, considering protections like ASLR and NX.

Mitigation and Fixes

Qualys and the OpenSSH developers collaborated closely to address this vulnerability. Here’s how to mitigate the risk:

Immediate Action: Set LoginGraceTime to 0 in sshd’s configuration file. This prevents exploitation but can cause denial of service due to exhaustion of all connections.
Patches: The vulnerability is fixed in commit 81c1099, which moves the risky code to a safer location. For those who can’t apply this update, a quick fix involves commenting out the problematic code in sshsigdie() and calling _exit(1) directly.

Why This Matters

This incident underscores the critical need for constant vigilance and quick action in cybersecurity. Despite its stellar track record, OpenSSH’s vulnerability shows that even the most secure software can have flaws.

Acknowledgments

Hats off to the OpenSSH developers for their swift response and ongoing excellence, and to the Qualys team for their thorough investigation and responsible disclosure.

Timeline

2024-05-19: Initial contact with OpenSSH developers.
2024-06-20: Notification to distros@openwall.
2024-07-01: Coordinated Release Date.

Final Thoughts

For developers and system administrators, this advisory is a reminder of the ever-present need for security diligence. Keep your systems updated, understand the risks, and always be prepared for the unexpected.

Source: Qualys Security Advisory