Return of SSH Race Condition: Regression Testing Chronicles

Prevention is the best security strategy for averting potential security threats before they become a real risk to the system. When teams focus on preventive measures and security controls, they can significantly reduce the likelihood of security incidents. Prevention includes planning, risk assessments, specialized and general security training for staff, and, most importantly, testing and validating security controls.

Vuln Deja Vu

Vintage is in style, and whenever I see what is now considered vintage, I cringe because that’s what I wore in high school or my early college days! I guess when something is that good, it has to come back. But, let’s not do that with vulnerabilitie.

Per OpenSSh advisory, a critical vulnerability in Portable OpenSSH, regreSSHion RCE (CVE-2024-6387), affecting versions 8.5p1 and 9.7p1 was earlier discovered by Qualys patched in release 9.8. The vulnerability received a nickname regreSSHion RCE, and it could allow an attacker to execute arbitrary code with root privileges and, as a result, would grant full control of the system. The vulnerability is a newly re-opened race condition in the sshd(8) daemon, a server-side component of the SSH protocol, due to a logic error in the code that handles the login grace timeout.

A similar vulnerability was discovered and patched in 2006. In 2006, OpenSSH fixed this issue in the release 4.5, and it is tracked with (CVE-2006-5051).

So far, regression RCE was successfully employed in a lab environment on a 32-bit Linux system with glibc (GNU C Library) and ASLR (Address Space Layout Randomization). ASLR is a security function within the Linux kernel that randomizes the memory addresses used by system and application processes. This enhances security by making it more difficult for an attacker to predict the location of specific data in memory. With ASLR, code that the attacker would manipulate is harder to locate, and the vulnerability would take longer to exploit, as it was in this case of a controlled lab environment - this required 6 to 8 hours to exploit.

The OpenSSH security advice for the temporary fix suggests disabling the login grace timeout. However, this may leave the system vulnerable to DoS attacks.

sudo nano /etc/ssh/sshd_config

# Set the value to Zero
LoginGraceTime 0

# Restart the sshd service
sudo systemctl restart sshd

# Alternatively, on older systems
sudo service ssh restart

# output should be "logingracetime 0"

Thank You!

The OpenSSH community is completing enormously important work, and their relentless dedication is a backbone to so many projects and technologies that we use daily. This collaboration drives technological advancements and fosters an environment where knowledge-sharing leads to continuous innovation.

Understand Regression Testing, You Will…

Regression Testing is a process of re-running previously completed tests to ensure that the existing functionality works as expected after a change to a code or the introduction of new functionality. It is an important type of testing within the Secure Software Development Life Cycle (S-SDLC), and it ensures that the new code change does not re-introduce previously fixed bugs or vulnerabilities. NASA recommends “perform regression testing after each change to the system” in addition to running tests for newly introduced functionality. This helps to ensure that new code changes do not introduce new bugs, re-introduce old issues, or affect existing functionality.

Regression Testing gives an opportunity to re-run a test for a specific bug or vulnerability that was previously fixed every time there is a change to the code. Your team is likely already doing this for the application’s main functionality, and adding security testing adds an extra oomph to the process will make a difference in the long run. Most of us would not enjoy doing this over and over again manually, and this is where automation with CI comes in handy.

Approaching Regression Testing: E-Commerce Example

The simplest way to approach this is to repurpose tests that were created for the initial bug or vulnerability testing. What would that look like in practice? Let’s say your team implemented a new payment gateway, and you completed a number of tests to confirm payment functionality. Great! Now, for Regression Testing, additional tests need to be added to ensure that all payment methods still work and that the entire checkout process is not affected by the new code change.

With Regression Testing as an automated step in your S-SDLC, you ensure that your application maintains reliability and security, changes do not compromise the integrity of the system, and previously fixed vulnerabilities are not re-introduced. Preventive steps like this are vital for delivering high-quality and secure software and preventing potentially costly security breaches and fixes in the future.