RCE Vulnerability In OpenSSH Server

Uploaded on 2024-07-02 in NEWS-Cybersecurity News, FREE TO VIEW, BUSINESS-Services-IT & Telecoms

Cyber security, problems often return, but rarely with such severity as seen in CVE-2024-6387, which has been dubbed "OpenSSHion." OpenSSH is a powerful collection of tools for remotely controlling networked computers and transferring data between them. The new vulnerability, assigned CVE-2024-6387, allows for unauthenticated remote code execution (RCE) with root privileges, posing a severe threat to affected systems.

Analysis of the cloud environments has found that 69% of organisations are using OpenSSH, either through a dependency or directly, and of those organisations 70% are using a vulnerable OpenSSH version.

SSH is widely used for accessing Kubernetes nodes and they’re also used sometimes within Kubernetes workloads, therefore this has a huge impact on cloud systems. The problem has been known about since 2005 but has now resurfaced, leaving millions of systems vulnerable to unauthorised control.

This discovery follows another major vulnerability found in the XZ Utils library just a few months ago, highlighting ongoing security challenges. Although CVE-2024-6387 is a serious flaw, it’s very hard to exploit in practice, and so far, no one has managed to use it to attack remote machines. Even so, it’s crucial to understand the risk and take steps to protect your systems.

An attacker could gain complete control of the affected system by executing arbitrary code with root privileges. This could allow the installation of malware, the creation of backdoors, and the exfiltration or manipulation of data. In addition, gaining root privileges could allow the intruder to disable or bypass critical security systems to maintain a permanent presence.

Commenting on this, Thomas Richards, principal consultant at the Synopsys Software Integrity Group, said, "OpenSSH has been the standard for SSH installations for a very long time. With OpenSSH being used pretty much everywhere, if this vulnerability is not patched, organisations are in danger of having their critical systems compromised. Organisations need to roll out this patch immediately for any internet-facing systems, including cloud systems. As an additional layer of security, firewall rules should be enabled only to allow SSH connections from trusted networks... I suspect we’ll see a rise in compromises of embedded and IoT systems, as many consumer models are meant to be disposable and rarely get updates..."

"A vulnerability like this could be used by attackers over a long period of time, as older systems do not get updates or as organisations are slow to patch." Richards said.

Technical Details

The new vulnerability has been discovered in OpenSSH’s server when a client fails to authenticate within the current time period, which is set to 120 seconds in current versions and 600 seconds in older versions. This problem is not completely new and is part of a previously identified issue reported in 2006. The earlier vulnerability also involved a signal handler race condition in OpenSSH versions prior to 4.4, which could lead to a denial of service or potentially allow remote code execution.

The implications of this vulnerability are particularly severe on glibc-based Linux systems, and creates a option where an attacker can use an arbitrary code as root without needing to authenticate. This is because OpenSSH privileged code operates with full system privileges and lacks sandboxing.

Exploitation

Exploiting the signal handler race condition vulnerability in OpenSSH requires a deep understanding of timing attacks and memory manipulation. The following section explains the steps an attacker would take to exploit this vulnerability, along with an example pseudocode to illustrate the process.

First, the attacker initiates multiple connections to the target OpenSSH server, which causes the server to raise the SIGALRM signal. Exploiting this vulnerability is not straightforward and typically requires around 10,000 attempts on average. Each attempt resets the LoginGraceTime timer, giving the attacker a new window to trigger the vulnerability.

During the exploitation process, the attacker adjusts the timing of their inputs based on feedback from previous attempts. This helps to fine-tune the timing required to successfully interrupt the signal handler at the critical moment. Modern systems have defences like Address Space Layout Randomisation (ASLR) and No-eXecute (NX) to prevent such exploits.

The attacker leverages predictable memory patterns and advanced timing techniques to bypass these protections. Successful exploitation allows the attacker to overwrite critical memory structures, leading to the execution of arbitrary code.

Security Teams Are Advised To Take The Following Action

Patch management: Apply patches for OpenSSH immediately and ensure continuous update processes.

Enhanced access control: Restrict SSH access via network-based controls.

Network segmentation and intrusion detection: Segregate networks and deploy monitoring systems to detect exploitation attempts.

Temporary mitigation: If the team can’t apply patches right away, configure LoginGraceTime to 0 to prevent exploitation, although this exposes systems to potential denial-of-service.

Marc Manzano, general manager for cybersecurity at SandboxAQ commented "... Any vulnerability allowing remote code execution opens the door to malicious actors that can have catastrophic consequences. Modern cryptography management platforms help companies monitor where this vulnerable version of OpenSSH is present across the IT infrastructure, providing an effective and seamless solution to address this situation in a timely manner."

Image: Ideogram

You Might Also Read:

Securing Kubernetes Helm: Vulnerabilities & Defensive Strategies:

If you like this website and use the comprehensive 7,000-plus service supplier Directory, you can get unrestricted access, including the exclusive in-depth Directors Report series, by signing up for a Premium Subscription.