Fwd: Inquiry about regreSSHion postmortem

[Loganaden Velvindron]

---------- Forwarded message ---------
From: Loganaden Velvindron <loganaden at gmail.com>
Date: Fri, 8 Aug 2025 at 10:26
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 think this blog post gives better context:
https://itwire.com/opinion-and-analysis-sp-481/open-sauce/life-in-the-trenches-an-openssh-developer-speaks.html

Working on OpenSSH is not easy given the huge number of platforms that
it needs to run on. I understand that he
works for a large search company. Ideally, he would be given a
reliable source of income and work full-time on OpenSSH.
How many companies are willing to pool resources to make that happen ?

Frankly, I'm amazed that more mistakes have not happened given how
small the team working on OpenSSH is vs the size
of the deployed openssh user base.


On Fri, 8 Aug 2025 at 09:49, Loganaden Velvindron <loganaden at gmail.com> wrote:
>
> 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