regreSSHion proved 'hard to exploit' is not a patch window

A lot of OpenSSH boxes sat unpatched for weeks after July 1, 2024, and the reason wasn’t a missing fix. The reason was a number. CVE-2024-6387 carries a CVSS of 8.1, and the conversation around it quickly turned 8.1 into “hard to exploit,” and “hard to exploit” into “I’ll get to it.” That chain of reasoning was wrong at every link, and it’s worth being specific about why.

What the score actually measured

The bug is a race condition in the SIGALRM signal handler in sshd. A client connects, fails to authenticate before LoginGraceTime expires (default 120 seconds), and the timer fires SIGALRM. The handler then calls functions that are not safe to call from a signal handler, including syslog(), malloc(), and free(). Hammer that path with enough unauthenticated connections and you can corrupt the heap, and with patient timing turn the corruption into unauthenticated remote code execution as root. Qualys named it regreSSHion and published the writeup the same day the fix landed.

The 8.1 is honest. It reflects that the race is finicky and the exploit is not a one-shot. What it does not reflect, because CVSS isn’t built to, is blast radius. This is sshd. It runs as root. It runs on effectively every Linux server you own. A score that says “this is fiddly to pull off” and a score that says “this is on every box in the fleet and lands you root” are two different statements, and only one of them made it into the planning conversation.

The part that got argued instead

The discourse settled on two facts, both true, and drew the wrong conclusion from them.

Fact one: on 32-bit glibc Linux, Qualys demonstrated reliable code execution in roughly 6 to 8 hours of sustained attack against a single target. Fact two: on 64-bit glibc Linux, ASLR makes the heap work much harder, and at disclosure Qualys called 64-bit exploitation theoretically possible but practically difficult.

“Practically difficult” got read as “not going to happen.” But 6 to 8 hours on 32-bit isn’t a theory, it’s a measured, demonstrated result. And “practically difficult on 64-bit” is a description of the technique available in July 2024, not a guarantee about the technique available next quarter. Exploitation gets cheaper over time; it does not get more expensive.

The other half of the rationalization was inventory. Plenty of teams told themselves they’re 64-bit everywhere and moved on. Most of them had never actually checked. 32-bit Linux hides in the places nobody audits: old VMs that never got rebuilt, IoT and edge gateways, container images built on a legacy 32-bit base that someone pulled three years ago and never revisited. “We don’t run 32-bit” is a belief until you’ve run the inventory, and the inventory is the part that got skipped.

Why the regression makes this worse

Here’s the detail that should have ended the debate. This exact bug class was already fixed once. CVE-2006-5051 was patched in OpenSSH 4.4p1 back in 2006, and that fix made the signal handler safe for eighteen years. During a refactor somewhere after OpenSSH 8.5p1 (released March 2021), the safety code was dropped, apparently as part of cleanup, and the old bug walked back in.

Every version from 8.5p1 through 9.7p1 on glibc Linux lost the protection. That’s not an exotic version range. That’s the band that covers essentially every actively maintained Linux install. So the question in front of an admin in July 2024 wasn’t “do I have some weird edge case,” it was “did any of my hosts upgrade OpenSSH in the last three years,” and the answer for most fleets is yes.

There was no patch excuse

The usual reason to defer a patch is that there’s no patch. That reason didn’t exist here. OpenSSH shipped 9.8p1 the same day as disclosure. Red Hat, Ubuntu, Debian, Amazon Linux, and SUSE had backports out inside 24 to 72 hours. The window where “I can’t patch yet” was a true statement was about three days wide. Everything after that was a scheduling decision dressed up as a technical one.

The honest version of the deferral was: “I read 8.1 and 6-to-8-hours and decided it could wait.” I don’t know how many of those decisions were made by someone who’d actually read the Qualys writeup versus someone who skimmed a headline and a severity badge. The result is the same either way. Root RCE in sshd got triaged like a medium because the score sounded like a medium.

Why this keeps happening

The structural problem isn’t OpenSSH and it isn’t the CVSS spec. It’s that we use one number to answer two questions, and the number only answers one of them. CVSS exploitability metrics describe how hard the bug is to weaponize. Patch prioritization needs to know what’s at stake if someone bothers. For a finicky bug on a low-value host, those align. For a finicky bug on the single most exposed root-privileged service in the building, they pull in opposite directions, and the score quietly answers the wrong one.

A bug that slips through is an accident. A process that reliably under-triages high-blast-radius services because the exploit is fiddly is a choice, and it’s a choice that gets made the same way every time a “complex” RCE in something critical shows up.

What to actually do with the next one

Treat the CVSS exploitability number as input about effort, not a verdict on urgency. When the affected service is sshd, or anything else running as root on every host, the blast-radius question outranks the difficulty question, and you patch on the patch’s timeline, not the exploit’s.

Concretely, for this one if you somehow still haven’t closed it: move to OpenSSH 9.8p1 or your distro’s backport, confirm whether LoginGraceTime is set explicitly because the default 120s is the exploitable timer, and actually run the 32-bit inventory instead of assuming. On hosts where patching has to wait, LoginGraceTime 0 stops the race, at the cost of letting unauthenticated connections sit open, which opens a connection-exhaustion door; document that trade where the next admin will find it.

The lesson outlives this CVE. “Hard to exploit” tells you how much an attacker has to spend. It tells you nothing about what they get when they spend it, and on regreSSHion what they got was root on your SSH daemon. That’s the number that should have driven the calendar. If you want the version of this judgment applied to the next critical before the discourse talks itself into waiting, that’s the call PatchDayAlert exists to make.

Sources

• NVD CVE-2024-6387 — 2024-07-01
• Qualys Security Blog: regreSSHion — Remote Unauthenticated Code Execution Vulnerability in OpenSSH server — 2024-07-01
• OpenSSH 9.8 release notes — 2024-07-01
• Red Hat CVE-2024-6387 advisory — 2024-07-01
• Ubuntu Security Notice USN-6859-1 — 2024-07-01