DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Monitoring Dynamic Linker Hijacking With eBPF
  • The DevSecOps Paradox: Why Security Automation Is Both Solving and Creating Pipeline Vulnerabilities
  • Building an OWASP 2025 Security Scanner in 48 Hours
  • DevSecConflict: How Google Project Zero and FFmpeg Went Viral For All the Wrong Reasons

Trending

  • DevOps and Platform Engineering Readiness Checklist: Everything Needed for a Scalable, Secure, High-Velocity Delivery Platform
  • Designing API-First EMR Architectures in .NET: Enabling Modular Growth in Compliance-Driven Systems
  • Architecting an Embedded Efficiency Layer: A Platform Deep Dive into Day-Two Operational Tuning
  • A Walk-Through of the DZone Article Editor
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. regreSSHion: Should We Panic About the New OpenSSH Vulnerability?

regreSSHion: Should We Panic About the New OpenSSH Vulnerability?

This article takes a detailed look at regreSSHion, a newly discovered vulnerability in OpenSSH that affects glibc-based Linux systems.

By 
Nikolai Mishin user avatar
Nikolai Mishin
·
Jul. 10, 24 · Tutorial
Likes (4)
Comment
Save
Tweet
Share
5.9K Views

Join the DZone community and get the full member experience.

Join For Free

What Is the regreSSHion Vulnerability (CVE-2024-6387)?

regreSSHion is a newly discovered vulnerability in OpenSSH that affects glibc-based Linux systems. regreSSHion (CVE-2024-6387) may allow arbitrary code execution with root privileges on systems with default configurations.

Why Is Everyone Worried About the regreSSHion Vulnerability?

Everyone is worried about the regreSSHion vulnerability because OpenSSH is a widely used utility for remote connection to different devices around the world. It implements the SSH (Secure Shell) protocol, which is integrated into most Linux distributions as well as macOS, OpenBSD, and FreeBSD. Furthermore, SSH is integrated into almost every device connected to the internet, from WiFi routers to baby monitors.

Affected OpenSSH Versions

Versions of OpenSSH up to 4.4p1, as well as those from 8.5p1 to 9.7p1 (inclusive), running on glibc-Linux, are susceptible to vulnerabilities. The OpenBSD version of OpenSSH is not affected, due to a security change introduced in 2021.

How To Mitigate a regreSSHion Vulnerability

Step 1: Update

First of all, you need to update the OpenSSH version if any updates are available.

The latest version of OpenSSH is 9.8/9.8p1.

  • Ubuntu prepared packages with updated versions:
    • Ubuntu 24.04 - 1:9.6p1-3ubuntu13.3 
    • Ubuntu 23.10 - 1:9.3p1-1ubuntu3.6 
    • Ubuntu 22.04 - 1:8.9p1-3ubuntu0.10

See the Release page for more information.

  • Debian:
    • bullseye (security), bullseye - 1:8.4p1-5+deb11u3 
    • bookworm (security) - 1:9.2p1-2+deb12u3 
    • sid, trixie - 1:9.7p1-7

More info is in the Debian bug tracker.

  • NixOS adds changes to all of the unstable, 24.05, and 23.11 channels. You can find more info in the nixpkgs GitHub.
  • FreeBSD OpenSSH versions are affected; you can find instructions on how to upgrade them in the Corresponding FreeBSD Security Advisory.
  • You can follow the publication of package updates in distributions on the pages of other projects: RHEL, SUSE/openSUSE, Fedora, Gentoo, and Arch.

Step 2: If No New Version Available

If no new SSH version is available, access to SSH should be restricted via a firewall or by any other network security tool.

Step 3: Update OpenSSH Configuration

Set LoginGraceTime to 0 to reduce the risk. Please note that this configuration can potentially increase the risk of denial of service attacks. You can do this manually or by using a simple remediation script.


How To Check If Your OpenSSH Is Vulnerable

The simplest method is to check the version and compare it with the affected list.

If you need to check many hosts, you can use the Python checker script by xaitax.

Does the regreSSHion (CVE-2024-6387) Vulnerability Means That Every Affected Version Will Be Hacked?

Not really. According to the official OpenSSH 9.8/9.8p1 release notes (linked in Step 1 above): 

"Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with address space layout randomization (ASLR). Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon.


Exploitation on non-glibc systems is conceivable but has not been examined. Systems that lack ASLR or users of downstream Linux distributions that have modified OpenSSH to disable per-connection ASLR re-randomisation (yes - this is a thing, no - we don't understand why) may potentially have an easier path to exploitation. OpenBSD is not vulnerable."

But this does not mean that you don't have to update the version! It is possible that hackers can find a faster way or use the same bug for a different type of attack.

Technical Details and Why the Strange Version Order Was Affected

Next, here are some technical details about what happened here and why the strange version order was affected by regreSSHion. This happened because exactly this bug was already fixed some time ago, and because of this, CVE-2024-6387 was named regreSSHion, a conjunction of "regression" and "SSH''. Previously, this bug had an ID CVE-2006-5051 and was reported by Mark Dowd in 2006, but it was accidentally brought back in the OpenSSH 8.5p1 (October 2020).

The OpenBSD version of OpenSSH is not affected, because its implementation from 2021 uses SIGALRM handler calls syslog_r() instead of syslog(), which is used in the affected OpenSSH versions.

Why Did One Recommendation Include the LoginGraceTime SSH Option Update?

Per a more detailed explanation from Qualys, if a client does not authenticate within LoginGraceTime (parameter specifies the time allowed for successful authentication to the SSH server, set to 120 seconds by default), then the SIGALRM handler is called asynchronously. 

But this SIGALRM handler calls various not async-signal-safe functions (syslog(), for example), which could lead to race conditions and allow a malicious code to run in the context of the sshd's privileged code, operating with full root privileges.

Сonclusion

In the detailed explanation from Qualys, they especially mention that “OpenSSH is one of the most secure software in the world," and, “...this vulnerability is one slip-up in an otherwise near-flawless implementation." But this bug one more time highlights how important regression testing is and how it can prevent a resurgence of previously identified vulnerabilities.

Secure Shell Vulnerability Linux (operating system) security ubuntu

Opinions expressed by DZone contributors are their own.

Related

  • Monitoring Dynamic Linker Hijacking With eBPF
  • The DevSecOps Paradox: Why Security Automation Is Both Solving and Creating Pipeline Vulnerabilities
  • Building an OWASP 2025 Security Scanner in 48 Hours
  • DevSecConflict: How Google Project Zero and FFmpeg Went Viral For All the Wrong Reasons

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook