---------- Forwarded message --------- From: Loganaden Velvindron <loganaden@xxxxxxxxx> Date: Fri, 8 Aug 2025 at 10:26 Subject: Re: Inquiry about regreSSHion postmortem To: Damien Miller <djm@xxxxxxxxxxx> Cc: Aaron Rainbolt <arraybolt3@xxxxxxxxx>, <rene.malmgren@xxxxxxxxxxx>, <adrelanos@xxxxxxxxxx>, <openssh@xxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxx> wrote: > > > > +openssh@xxxxxxxxxxx > > +openssh-unix-dev@xxxxxxxxxxx > > > > 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@xxxxxxxxxxx > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
