Qualys disclosed regreSSHion on 1 July 2024: a signal-handler race in sshd
giving unauthenticated remote code execution as root on glibc-based Linux
(Qualys).
OpenSSH 9.8 shipped the fix the same day
(OpenSSH).
It is a regression, in Qualys's framing: the reintroduction of CVE-2006-5051, an eighteen-year-old bug that came back in OpenSSH 8.5p1 in March 2021. So the affected range has an odd shape. Below 4.4p1 vulnerable, unless backport-patched for CVE-2006-5051 or CVE-2008-4109. From 4.4p1 up to but not including 8.5p1, safe. From 8.5p1 through 9.7p1, vulnerable again; 9.8p1 is the fix.
That shape is why this one is harder to scan for than it looks.
Why the version number does not answer the question¶
A distribution backports a security fix without changing the upstream version string. So a host reporting OpenSSH 9.6p1 sits squarely in the affected range and may be perfectly safe, because the vendor patched it last Tuesday and left the version alone.
Reading sshd -V therefore tells you almost nothing on its own. The package
version against the distribution's fixed version is what decides, and that only
works where a package exists and where you know what the fixed version is for
that release.
Which leaves a third category, and getting it right is the only interesting decision in the tool: a packaged OpenSSH in the affected range, on a distribution our configuration has no fixed version for. The tempting answer is to call it vulnerable and let the operator sort it out. We report it as unknown.
A false "vulnerable" on a patched host sends someone to apply a workaround that costs availability, for no gain. A false "fixed" is worse. "Unknown" is the only verdict that is true, and it carries the one instruction that is also true: go and look at this host yourself.
The workaround is not free¶
The vendor-documented mitigation is LoginGraceTime 0. Qualys is blunt about
what it costs: it "makes sshd vulnerable to a denial of service (the exhaustion
of all MaxStartups connections)". Connections that have not yet authenticated stop
being timed out, so anyone can hold every slot open and nobody can log in.
You are choosing which outage you prefer. Unauthenticated root on an internet-facing box is worse than an SSH denial of service, so for most estates the trade is correct, and it is still a trade rather than a fix. Red Hat pairs it with fail2ban and a firewall, which is sensible, and turns one moving part into three.
Our role at
github.com/axisops/CVE-2024-6387,
MIT, upgrades openssh-server first and only applies the workaround to hosts
still vulnerable afterwards. Same ordering as every tool in this family, for
the same reason: the workaround should reach the smallest possible number of
machines.
One line, in the right place¶
The line goes at the top of sshd_config, and that is not a style
preference.
sshd keeps the first LoginGraceTime it reads. Ubuntu 22.04 onwards puts an
Include sshd_config.d/*.conf at the start of the file, so a directive appended at the end loses to anything in that directory that sets
the same keyword, because the first value read wins. The
workaround appears in the config, reads correctly to anyone reviewing it and
does nothing at all.
The other half of that trap is removal. Installing the fixed package does not take the lines out. An estate that applied the workaround in July and upgraded in August is still running without login timeouts in September, carrying the denial-of-service exposure it accepted as temporary, because nothing connects the two operations. Take the lines out as a deliberate step after the upgrade, and check for them on hosts you believe are clean.
What it does not do¶
The workaround trades a remote root for an availability risk, and this role applies it without asking whether your box is behind a bastion or facing the internet. That judgement is yours and the tool cannot make it.
Version detection depends on sshd -V, falling back to ssh -V, and on dpkg
or rpm. A self-built OpenSSH in /usr/local has no package to compare
against and lands in "unknown" by design. Containers running their own sshd are
not covered by a host scan at all; their fix is a rebuilt image.
And it contains no exploit code, so it cannot tell you whether a host is exploitable, only whether it is in the affected set. Qualys's own exploitation figures are hours to days of sustained connection attempts against a tuned target. That is a real attack and not a drive-by, which should inform how you rank this against everything else in the queue rather than whether you act.
The five days¶
The fix was available on day one. We published on day five, and all of it went on the classification problem rather than the change.
Reading the advisory takes twenty minutes. Working out which of your hosts are genuinely affected means knowing every distribution and release you run, every vendor's fixed package version for each and which of those vendors had shipped by the time you looked. None of that is in the advisory, and none of it is knowable from the version string the host reports.
An estate that can answer "what OpenSSH, from what package, on what release" from a declaration does this on day one. We went looking, host by host: the same answer we reached in December 2021, and one we have not yet finished building our way out of.