Fwd: Inquiry about regreSSHion postmortem

Fri Aug 8 16:37:03 AEST 2025

---------- Forwarded message ---------
From: Loganaden Velvindron <loganaden at gmail.com>
Date: Fri, 8 Aug 2025 at 09:49
Subject: Re: Inquiry about regreSSHion postmortem
To: Damien Miller <djm at mindrot.org>
Cc: Aaron Rainbolt <arraybolt3 at gmail.com>,
<rene.malmgren at redtoken.ae>, <adrelanos at whonix.org>,
<openssh at openssh.com>

I would back Damien's assessment. Mistakes do happen, even in OpenBSD.
The OpenBSD team
has done good work to responsibly disclose in the past and alert their
user base.

I also sent a diff a long time ago (2013 ?ish) that introduced a
TOCTOU in OpenBSD's mg despite it being peer-reviewed.

Damien and the openssh team have argued publicly for x25519-sntrup761
key exchange
support in OpenSSH despite sntrup it not being selected by NIST. They
have stated publicly that they will
not implement Pure PQ algorithms.

If you look at their track record since 1999, you observe a definite
pattern of careful engineering decisions (hybrid kex,
privsep, seccomp, pledge, x25519, non approved nist ciphers like
chacha20-poly1305),
As I stated above, OpenBSD projects can make mistakes despite careful
review. I'm very skeptical that those are intentional.

On Fri, 8 Aug 2025 at 06:13, Damien Miller <djm at mindrot.org> wrote:
>
> +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
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev