The bug occurred before authentication
OpenSSH 9.8, released on 1 July 2024, fixed a critical race condition in the portable server. The upstream release notes identify versions 8.5p1 through 9.7p1 as affected by CVE-2024-6387. Qualys, which reported the issue, called it regreSSHion because a previously addressed class of vulnerability had reappeared.
The problem concerns asynchronous signal handling in the server's authentication timeout path. This makes an important operational distinction: requiring SSH keys does not remove a flaw reached before a client has authenticated. Key-only access remains useful, but it answers a different security question.
Keep the demonstration attached to its conditions
The 9.8 release notes describe demonstrated exploitation on 32-bit Linux/glibc systems with ASLR and an average of six to eight hours of continuous connections under laboratory conditions. The same disclosure said exploitation on 64-bit systems was considered possible but had not been demonstrated there at that time. OpenBSD was not vulnerable.
These are statements about the evidence at disclosure, not a guarantee about every later exploit or every deployment. A retrospective should preserve that time boundary rather than silently turning an initial limitation into a permanent assurance.
Triage the server, not the workstation's client
Running ssh -V usually tells an administrator about the client executable in that environment. It does not prove which server package a remote host runs or whether the distribution backported a fix. This is a common mismatch between a convenient command and the question that needs answering.
| Evidence | What it establishes | Remaining work |
|---|---|---|
| Server package release | Installed distribution build | Compare with that distribution's advisory |
| Service and process state | What is running now | Confirm the fix reached the running daemon |
| Network access policy | Who can reach the listener | Include IPv6, alternate ports and management paths |
| Upstream version | Useful vulnerability context | Account for vendor backports and platform differences |
A banner or scanner finding is a lead to reconcile with package evidence. Treating every older upstream number as unpatched will produce false positives on supported distributions that backport security fixes.
A maintenance sequence that avoids a second incident
Identify the server's package source and affected status using the operating-system vendor's guidance. Prioritise internet-reachable listeners and systems with weaker network restrictions. Stage the update using the supported package mechanism and verify the running service after the documented restart or reload procedure.
Before changing SSH access on a remote server, preserve a working administrative session and confirm that a separate recovery route exists. This is an availability precaution: a correctly patched daemon is of little immediate help if an unrelated configuration mistake prevents every administrator from connecting.
Record the package release, verification time, host owner and the evidence used to close the ticket. Keep the original exposure decision if it matters to an incident investigation. A queue containing only “OpenSSH updated” cannot distinguish an updated client from a remediated server.
Why xz belongs in the comparison
The xz incident also led responders towards SSH, but by a different route: malicious dependency build material rather than this server race condition. The overlapping service name is not a shared root cause. One case demands artefact provenance and linkage analysis; the other requires affected server implementation and patch verification.
FISRO's assessment is that management-plane exposure deserves its own asset record. Keep authentication strength, pre-authentication software risk and recovery access as separate fields. Improving one of them should not make the other two disappear from review.
Backported fixes have their own version boundaries
The Debian tracker records 1:9.2p1-2+deb12u3 as the bookworm fix boundary for CVE-2024-6387. Ubuntu records 1:9.6p1-3ubuntu13.3 for Ubuntu 24.04 LTS. Both illustrate why a supported distribution package can retain an upstream number below 9.8p1 while carrying the correction.
| Packaging context | Recorded historical fix | Evidence |
|---|---|---|
| Portable OpenSSH upstream | 9.8p1 |
OpenSSH 9.8 release notes |
| Debian bookworm | 1:9.2p1-2+deb12u3 |
Debian CVE tracker / DSA-5724-1 |
| Ubuntu 24.04 LTS | 1:9.6p1-3ubuntu13.3 |
Ubuntu CVE-2024-6387 record |
These are historical boundaries for the named contexts, not current recommended package versions. Other releases and vendor builds require their own evidence. The Debian record also distinguishes bullseye as not affected; that conclusion does not derive simply from its number being older.
Check the installed server and the process state
On a Debian-family host, read the full server package release:
dpkg-query -W -f='${Package}\t${Version}\n' openssh-server
On an RPM-managed host, query the server package using the supported package database:
rpm -q openssh-server
Then inspect the service state and process start time through the operating system's service manager. On a systemd system whose unit is named ssh.service, a bounded read is:
systemctl show ssh.service -p MainPID -p ActiveEnterTimestamp
Some systems use sshd.service; use the installed unit name. These records do not prove that the process loaded the expected fix. Reconcile the package transaction and the vendor's required restart procedure with the actual service state. A long-running daemon that predates the relevant update needs attention even when the package database looks correct.
The timeout condition and its trade-off
The issue involved sshd's handling of a signal after a client failed to authenticate within LoginGraceTime. Qualys identified a regression of CVE-2006-5051. This is a direct historical precedent in the same failure class, unlike the unrelated malicious dependency route in xz.
Ubuntu's record describes setting LoginGraceTime to zero as a mitigation and explicitly notes a denial-of-service trade-off involving exhaustion of unauthenticated connection slots. That is not a setting to copy silently into production. Prefer the supported software correction and assess any temporary measure with the service owner.
ProxyLogon and ScreenConnect provide useful operational comparisons: authentication strength does not remove a vulnerable route reached before normal authentication. Their code paths and persistence questions differ, so use the OpenSSH-specific platform and process evidence here.
The closure decision should identify the full vendor package, running daemon, reachable listener and retained recovery access. Keep any investigation of suspicious earlier activity as a separate decision rather than inferring it from the update result.