Dark Mode

    Free Trial
    Image of Bar Shay
    • 7 min read
    • Jul 3, 2024 12:38:42 PM

    Defending Against RegreSSHion (CVE-2024-6387)


    After a CVE is published, the race is on. Often a good amount of time passes before any patches are issued. Of course, sometimes the patch never comes. Best case scenario, patches are released together with the disclosure or shortly thereafter.

    Even in that best case scenario though, near-term risks increase significantly after a disclosure. Even when patches are made quickly available, in many cases, internal processes will slow the deployment of those patches. In the meantime, companies will need to take some practical steps mitigate their exposure.

    A Familiar Dilemma

    This is where many organizations get into trouble. The fastest path to protection is usually the most sweeping. If they can disable the vulnerable service or protocol wholesale, they do. But that's not always an option.

    If the organization built other technological or operational dependencies on top of the service or protocol in question, the fastest approach to security would bring significant harm to the business.

    In most cases though, businesses don't actually have a clear view of their interdependencies. Certainly not off-hand. Most don't immediately know all the ins and outs of how the business utilitizes specific stack components and how those components interact with each other.

    And so as decision-makers seek to balance the risks of attack against the risks of business disruption, they'll typically err on the side of an expanded attack surface. Of course, they'll compensate for this by taking measures to harden — at least temporarily — their segmentation, detection, and response regimes. But that's rarely enough.

    It's this sort of damned if you do, damned if you don't risk management that dominates the immediate aftermath of a critical vulnerability disclosure. And that's exactly what we're watching play out now with RegreSSHion. 

    The RegreSSHion Vulnerability

    A critical race condition vulnerability was discovered in the OpenSSH server process on glibc-based Linux systems. The vulnerability, documented as CVE-2024-6387 and named RegreSSHion, was published by Qualys on July 1, 2024. It is considered highly severe (8.1 CVSS v3) and can bypass security mechanisms to breach systems and leak sensitive information.

    A security regression predicated on a lapsed authentication window, the vulnerability makes it possible to remotely execute arbitrary code with the highest privileges. This opens the door to complete system takeover, malware installation, data manipulation, and the creation of backdoors — all without need for prior authentication.

    This vulnerability affects sshd in its default configuration, putting many organizations at high risk.

    Remediating RegreSSHion

    1.  Check your device’s vulnerability

    Refer to your OS provider’s official website for up-to-date information on vulnerable versions. Major distributions such as Debian, Ubuntu, RHEL, and SUSE have released advisories and patches. 

    2.  Apply a patch

    For affected systems, install legitimate patches as soon as they are made available. If an asset is affected, but there is not yet an available patch (or patching will be otherwise delayed), refer to fallback and regularly check the vendor website for updates. 

    Fallback Defense Against RegreSSHion

    If you have affected systems that are not eligible for patching or for which patching delays are expected, please take the following steps:

    1.  Identify & close unused daemons

    Identify and immediately close any OpenSSH server daemons that are not in use. At GYTPOL, we look back 90 days to determine whether or not the relevant service is in use. With that distinction built into the system, GYTPOL automatically surfaces quick-win opportunities where hardening actions can be taken without any risk of disruption. 

    2.  Configure LoginGraceTime

    If patching is not immediately possible, set the LoginGraceTime field to 0 in the sshd_config file. This file is typically located at /etc/ssh/ssh_config. While this mitigates the RCE threat, it exposes your system to Denial of Service (DoS) attacks. Though not ideal, this can be a decent interim solution for closed networks with stringent update policies.

    3.  Enhance security policies and perimeter controls

    Use this opportunity to review and tighten your device configurations. Be sure you have proper segmentation regimes in place, continuous perimeter monitoring, and rapid response capabilities. Policies should be examined and updated where necessary to ensure comprehensive security and strict enforcement. 


    Using LoginGraceTime to protect against RegreSSHion provides a good example of how DIY mitigations so often falter. The dependencies are opaque, the consequences can be hard to anticipate, and the risks are multivariate.

    Setting the LoginGraceTime parameter to 0 makes the SSH service more susceptible to denial of service attacks. Obviously, DoS is preferable to RCE, but it's not quite that simple. RegreSSHion affects a relatively small subset of Linux-based systems. Regardless of the severity then, you don't want to open a lot of devices to one problem just to protect a few devices from another.

    In this case, it's also worth noting that a DoS attack is a lot easier to carry out than an RCE exploit on RegreSSHion. In fact, with LoginGraceTime set to 0, it's conceivable that a DoS could even happen incidentally, without any outside interference.

    And there's the rub. Blanketly applying this mitigation will increase your operating risk while at the same time lowering your exposure. It's not a great option. On the other hand, a more targeted approach — identifying and applying the LoginGraceTime mitigation only to those assets in your fleet with the relevant OS, distribution, and OpenSSH versions — can take a good amount of time to work out and leave you exposed in the lengthy interim. Also not great. 

    Seeking A Silver Bullet

    This sort of dilemma perfectly demonstrates why we made GYTPOL — to eliminate damned if you do, damned if you don't tradeoffs. With GYTPOL, you can protect against RegreSSHion without introducing any new or undue risks — all with the push of a button.  It's a solution designed to be uncompromising — always fast, always secure, and always non-disruptive.

    At GYTPOL, we continuously monitor and map affected versions, providing you with the latest information and a one-click path to remediation.

    We offer comprehensive configuration policies for SSH and beyond — ensuring that you can implement best practices efficiently and effectively.  And GYTPOL doesn't just issue recommendations, but actually makes it possible to push remediations with the push of a button. No lost time. No open gaps. No new risks.


    Special thanks to Dima Krasnser and Yair Mishaly from the GYTPOL research team in assisting with this article.

    See for yourself how GYTPOL delivers tailored and timely vulnerability  remediation »

    About Author

    Image of Bar Shay

    Bar Shay

    Software Engineer and researcher at GYTPOL, Bar is a graduate of Magshimim, Israel's national cybersecurity program, prior to which he served in Unit 81, one of the IDF's most elite cyber units. Bar has a background in IT and software development.