Inquiry about regreSSHion postmortem

[Damien Miller]

+openssh at openssh.com
+openssh-unix-dev at mindrot.org

If I'm to be accused of deliberately or incompetently inserting bugs
into OpenSSH, I'd prefer the conversation happen in public.

On Thu, 7 Aug 2025, Aaron Rainbolt wrote:

> Hi Damien,
> 
> You probably remember me from the thread about post-quantum-secure
> signature algorithms for openSSH. I'm a contributor to the Kicksecure
> and Whonix projects, two Debian derivatives that attempt to provide
> above-average security by hardening configuration, improving isolation
> between privileged and unprivileged operations, and educating users on
> how to avoid making common mistakes that can lead to compromises or
> increase attack surface. Since we're firmly in the "paranoid security"
> community, we occasionally get feedback from users that may seem a bit
> odd at first glance, and some of said odd feedback is what led to this
> email.
> 
> A user who wishes to remain anonymous sent us a document arguing that
> the way in which regreSSHion (CVE-2024-6387) was introduced was, in the
> user's words, "unreasonably careless". They appear to have looked
> through the OpenSSH Git commit history to analyze the history of
> CVE-2006-5051 and the surrounding code, and how it relates to
> CVE-2024-6387, then made their conclusion based on how the code changed
> over the years. The document references a blog post written by René
> Malmgren (who is CC'd on this email), who argues that the vulnerability
> was likely "reintroduced intentionally", using a much shorter analysis
> of some of the same Git commits. The user did not entirely agree with
> René's assessment, but still found some of the circumstances
> surrounding regreSSHion to be worrying enough that they contacted us
> about it.
> 
> Given our focus on security, we obviously want to act on such feedback
> if (and only if) it is reasonable. But given our not-very-strong
> understanding of OpenSSH's internals, lack of familiarity with the
> project's development procedures, and positive statements from others
> about OpenSSH's internal design and security, we aren't really sure
> what to make of this. Both of the writeups are likely missing context
> since they're based mostly on Git commits and commit messages, and
> neither individual appears to have any familiarity with OpenBSD
> development practices. I talked about this with the lead Kicksecure
> developer ("adrelanos", who is also CC'd on this email), and we decided
> it would probably be a good idea to forward the documents to you in
> case you wanted to comment on them. I've attached the document to this
> email.

The regreSSHion bug was my mistake.

How was the bug introduced? In a commit (752250caa) that improved
OpenSSH's logging framework, a portable-OpenSSH specific #ifdef was
incorrectly dropped.

How did this happen? It's the reason that Occam's Razor would
suggest - two portable-specific lines got lost in a ~500 line diff
due to a human error (mine) while merging.

How did the human error go unnoticed? Essentially all non-trivial
changes to OpenSSH are reviewed before being committed, but the merge
process is not reviewed again. Mistakes made in manually merging
changes with conflicts can go unnoticed.

Could we do better here? With more resources, sure. The critics you
cite can help here by looking themselves. The commits are all public,
and attributed and we provide a 1:1 mapping to originating OpenBSD
commits via the OpenBSD-Commit-ID marker in the commit message.
Finding other mistakes of this nature should be simple for them,
should they exist. I invite them to look.

How did we respond to this problem? By improving the architecture of
sshd and introducing controls that make exploitation of any non-
deterministic bug significantly harder to exploit. It's IMO weird
that your anonymous accuser treats this work as somehow evidence
of further incompetence.

Was this a intentional backdoor? Obviously a denial would be
redundant here, but if it was a backdoor then it would be a pretty
ineffective one. The attack has a low probability of success even
under ideal circumstances, taking many hours and being extremely
noisy in the process. A year after discovery, I'm still not aware
that anybody has make a successful exploit for 64-bit systems.

Compare this to actual backdoors, such as Dual_EC_DRBG or the xz
incident and you can see that it's missing two critical features:
1) determinism (as mentioned above) and 2) NOBUS - "no-one but us",
the property that the backdoor is only usable by its originators.

Draw your own conclusions from this.

-d