FAQ: The RegreSSHion vulnerability and GitLab

Here is what you need to know about RegreSSHion (CVE-2024-6387), a recently discovered remote unauthenticated code execution vulnerability, how it impacts GitLab, and how to mitigate the risk in your GitLab environment.

What is RegreSSHion?

The Qualys Threat Research Unit recently discovered the RegreSShion flaw, which is a signal handler race condition in OpenSSH’s server (sshd). RegreSSHion allows for an unauthenticated attacker remote code execution (RCE) as root on glibc-based Linux systems and presents a significant security risk. This race condition affects the OpenSSH sshd daemon in its default configuration.

Does RegreSSHion impact GitLab customers?

1. GitLab.com and GitLab Dedicated are not impacted by RegreSSHion because they use gitlab-sshd, which is not vulnerable to RegreSSHion. Gitaly uses gitaly-ssh, which is not vulnerable to RegreSSHion.

2. Self-managed GitLab customers might require patches to their environments.

   • If your self-managed GitLab instance is cloud-based and the cloud provider maintains the underlying operating system, your environment is safe because all of the major Linux platforms have upgraded their libraries.
   • If you are responsible for maintaining the core operating system for your self-managed instance and you have installed the latest patches, your environment should be safe.
   • Self-managed instances can be configured to use gitlab-sshd, which is not vulnerable.

If your GitLab instance is not open to the public, you have substantially reduced levels of risk.

Note: If you develop and manage your own Docker containers, you are encouraged to apply patches to them as well.

What can you do to mitigate RegreSSHion?

Unpatched environments have a low risk of impact from RegreSSHion due to the nature of the flaw and the general chaos of traffic flow on the internet. Most attackers wanting access to systems would likely choose an easier path, such as phishing. To protect your environment we advise you to follow the GitLab Hardening Recommendations. We recommend the basics of regular patching, strong passwords, and implementing multi-factor authentication on all your systems, including your GitLab instance.

What is GitLab doing to monitor RegreSSHion?

As the most likely attack scenario involves an attacker making rapid, repeated attempts over a long time (days), normal monitoring and defenses against denial-of-service attacks are already actively monitored and defended against. Logs are monitored and reviewed for various types of anomalies, and this particular attack would be detected if attempted. And, as noted above, GitLab.com and GitLab Dedicated are using gitlab-sshd, which is not vulnerable.

How else can you harden your environment against RegreSSHion and similar vulnerabilities?

If you want to take further steps to help ensure you’ve reduced the risk as much as possible, here are a few general guidelines for handling mitigations of your GitLab environment:

• If for some reason you cannot upgrade the underlying operating system, use gitlab-sshd as it is easy to configure. OpenSSH is written in the C programming language, which has historically allowed for the introduction of memory errors. Note that gitlab-sshd is written in Go, which is generally considered a “memory safe” language.

• Follow the guidelines in the GitLab Hardening Recommendations. For example, setting the /etc/ssh/ssh_config values specified in these recommendations could cause the exploit code to fail. Typical exploit code might have problems dealing with a specific hash-based method authentication code (HMAC) value or algorithm specified. Additionally, some of the recommended /etc/sysctl.conf settings will also increase exploitation difficulty. This could substantially increase the number of attempts needed.

• In some recommendations regarding mitigating RegreSSHion, there have been references to setting the LoginGraceTime to 0 in the /etc/ssh/sshd_config file. This will result in your system not being vulnerable to RegreSSHion, however, it will now be vulnerable to a denial-of-service attack. If unspecified, the LoginGraceTime defaults to 120 seconds. It is considered best practice to set the LoginGraceTimethis to 60 seconds, and this effectively doubles the time required for a successful RegreSSHion attack. Note:gitlab-sshd defaults to 60 seconds.

What is the potential result of the RegreSSHion vulnerability?

The attack was developed and tested in Qualys’ lab environment, which is not reflective of a normal internet-accessible environment. If the attack works, it can be devastating. However, even in this controlled environment Qualys could only get an attack to be successful once every 10,000 attempts on older CPUs in a process that took hours. On modern CPUs this could take a week or more in a pristine lab environment. On the open internet with regular traffic and the potential for even further delays, the chances for a successful attack are substantially reduced. In other words, it could be very bad if it works (an attacker executing commands of their choice remotely), but the odds of it working in a real-world environment are extremely remote.