When the Lock Opens Itself
Think about how you lock your front door. You expect the latch to stay bolted until someone turns the right key. Now imagine a lock that gets confused if someone jiggles the handle over and over at exactly the right speed. Instead of keeping people out, it just pops open.
That’s basically what happened with one of the most trusted security tools on the internet. India’s Computer Emergency Response Team, called CERT-In, put out an urgent warning (CIVN-2024-0214) about a serious bug in OpenSSH. The flaw is tracked as CVE-2024-6387 and nicknamed “regreSSHion.” It lets attackers who haven’t even logged in take full control of Linux servers.
What Went Wrong With OpenSSH?
OpenSSH is free, open-source software that administrators use to manage remote cloud servers safely. It builds an encrypted tunnel between an engineer’s laptop and a faraway machine.
The problem is something called a signal handler race condition in the OpenSSH server program, known as sshd. If someone connects but doesn’t log in during the login grace time, which is 120 seconds by default, the server sends itself a signal. That signal sets off code that uses memory in an unsafe way. If an attacker times things just right, they can win the “race” and get root access, which is the highest level of control, without any password.
Why Locked Accounts Don’t Save You
Linux keeps account passwords in a protected file called /etc/shadow. When an admin turns off password logins for an account, the password field starts with an exclamation mark (!) or an asterisk (*). Those symbols tell the system that there’s no valid password, so any password check should fail.
The catch is that this attack hits the server before the account checks even finish. The attacker hijacks the background process in memory, so the locked-account setting never gets a chance to matter.
Why This Is Hard to Deal With
This is a big deal for modern systems, especially automated build pipelines and cloud containers. Winning the race takes thousands of connection attempts, but attackers with fast internet can keep hammering any server that’s open to the public.
Big companies also have a hard time fixing it. Updating and restarting the SSH program across lots of live containers is a pain. Teams often put off patches because they worry a restart will cut off monitoring sessions or break other services.
How to Fix It
Engineers should upgrade to OpenSSH version 9.8p1 or newer right away, since it removes the unsafe code.
If they can’t upgrade yet, there’s a quick workaround. Open /etc/ssh/sshd_config, set LoginGraceTime 0, and reload the service. This stops the race condition from happening, but it has a downside. Attackers can hold connections open and overload the server, which is called a denial-of-service attack. The safest option is to limit access to port 22 using hardware firewalls or a private VPN.
