regreSSHion: Unauthenticated Remote Code Execution in OpenSSH

regreSSHion - The return of a 18 year old vulnerability

Qualys, a security company, recently unveiled a unauthenticated Remote Code Execution (RCE) vulnerability in OpenSSH’s server (also known as sshd), present in glibc Linux operating systems.

According to their press release, there are around 14 million potentially vulnerable OpenSSH instances exposed to the Internet.

Why should you care about regreSSHion?

• This is a remote vulnerability, so it can be exploited over the network.
• Since sshd runs as root, exploiting this vulnerability would give an attacker root access to the system.
• Furthermore, the vulnerability affects the default configuration of the OpenSSH server.

You should avoid exposing SSH directly on the Internet, but in case you’re one of the people who must do that, make sure to patch quickly! Enterprise users should patch their internal servers to avoid enabling easy lateral movement inside their networks.

Why regreSSHion?

Riding the trend of giving CVEs catchy (or not) names, this one comes from the fact that the bug is a regression of CVE-2006-5051, which was reported, you guessed it, in 2006. What is a regression? For the non software engineering readers out there, a regression happens when a software bug is fixed but it’s reintroduced by a code change later on in the future. QA and developers should be familiar with the term of “regression testing”. Which is a type of testing and quality assurance that is meant to precisely prevent issues like this one. Basically attempting to avoid old mistakes.

Affected OpenSSH versions

This is were it gets a bit complicated and makes assesment harder for defenders.

• Versions older than 4.4p1 - vulnerable, unless its patched for CVE-2006-5051 and CVE-2008-4109
• Versions from 4.4p1 -> 8.5p1 (excluding) - not vulnerable
• Versions from 8.5p1 -> 9.8p1 (excluding - vulnerable

It’s worth mentioning that OpenBSD systems are not vulnerable due to a security mechanism introduced by OpenBSD in 2001 that prevents the vulnerability.

Impact of regreSSHion

As already mentioned, successful exploitation of this vulnerability provides an attacker with root access to the target system, thus giving the actor full control over the machine.

On the bright side, exploitation requires winning a race-condition happening in the code (which apparently takes around 10,000 attempts). This means that success requires a number of attempts. Furthermore, memory protections like ASLR must be defeated so it requires extra attempts, especially on 64 bit systems (in theory, the attack duration grows from hours to days, but the attack wasn’t proven on 64bits yet).

Because of the complexity of the exploit (requiring glibc version specific structures), a wide spread attack campaign is highly unlikely. An attacker must know in advance what Linux distribution they are targeting in order to build a functional exploit.

Vulnerability description

If an SSH client fails to authenticate within the LoginGraceTime period (120 seconds by default), then the SIGALRM handler is called asynchronously. However, some of the functions that it calls are not async-signal-safe, including syslog(). In glibc Linux flavors, syslog() might call (under specific conditions) the async-signal-unsafe functions malloc() and free().

If calls to any of these functions are interrupted by code that also calls a heap-related function, it could lead to heap corruption. If done correctly, the heap can be arranged/groomed in a specific way that leads to arbitrary code execution.

How to mitigate regreSSHion?

1. Update your OpenSSH server instances to 9.8p1 or newer
   • alternatively you can set LoginGraceTime to zero which will prevent the RCE, but will expose the server to a denial of service attack. Make sure you fully understand the impact of this setting before applying it.
2. Apply network level access controls to reduce the attack risk
3. Monitor - use an IDS (or IPS), your SIEM or whatever tools you have at your disposal

How can I tell if someone tried to exploit my system via this vulnerability?

Exploitation attempts for regreSSHion can be identified by observing lots of log lines containing “Timeout before authentication”. By lots, I mean several thousands. According to the technical paper, exploiting the race condition requires around 10,000 attempts on 32 bit systems, which might take around 4 to 6 hours. On 64 bit systems it can take days (but less than a week, according to Qualys) because defeating ASLR is a lot harder. The paper is really fascinating and goes into nice details on how they exploited the original vulnerability first and what they had to overcome to bring it up to date. It’s a really good read if you’re interested in this type of things, so a fully recommend you check it out.