[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<BL1PR01MB772375CA93AF5608280A224FC118A@BL1PR01MB7723.prod.exchangelabs.com>
Date: Sun, 28 Sep 2025 15:22:43 +0000
From: "Adiletta, Andrew" <ajadiletta@....edu>
To: Theo de Raadt <deraadt@...nbsd.org>, Damien Miller <djm@...drot.org>
CC: Solar Designer <solar@...nwall.com>, "oss-security@...ts.openwall.com"
<oss-security@...ts.openwall.com>, "openssh@...nssh.com"
<openssh@...nssh.com>, "Tol, Caner" <mtol@....edu>, "Sunar, Berk"
<sunar@....edu>, "Doroz, Yarkin" <ydoroz@....edu>, "Todd C. Miller"
<Todd.Miller@...rtesan.com>, "pgut001@...auckland.ac.nz"
<pgut001@...auckland.ac.nz>
Subject: Re: [EXT] Re: CVE-2023-51767: a bogus CVE in OpenSSH
Theo,
Even after two years we stand behind our paper and the contributions as outlined. There is nothing more natural for any vulnerability researcher to evaluate the most widely used products. If we had doubts about the claim or any of the POCs, we would have simply not included them in the paper.
As far as SSH is concerned there are ways to handle synchronization (we outline them in the paper). The POC concept we present in the paper should be acceptable to anybody who is fluent in the Rowhammer/microarch attack literature. There are numerous results where the target is slowed down to solve synchronization. We don’t brush aside or hide the synchronization issue in the paper but discuss it explicitly.
As for the change in the abstract that Damien suggested, we actually were ready to implement it. But then you interfered and said it’s not going make a difference.
Regardless, it looks like we should actually clarify the SSH case further with a couple of sentences in the abstract and update the arXiv version.
________________________________
From: Theo de Raadt <deraadt@...nbsd.org>
Sent: Sunday, September 28, 2025 10:12:26 AM
To: Damien Miller <djm@...drot.org>
Cc: Adiletta, Andrew <ajadiletta@....edu>; Solar Designer <solar@...nwall.com>; oss-security@...ts.openwall.com <oss-security@...ts.openwall.com>; openssh@...nssh.com <openssh@...nssh.com>; Tol, Caner <mtol@....edu>; Sunar, Berk <sunar@....edu>; Doroz, Yarkin <ydoroz@....edu>; Todd C. Miller <Todd.Miller@...rtesan.com>; pgut001@...auckland.ac.nz <pgut001@...auckland.ac.nz>
Subject: Re: [EXT] Re: [oss-security] CVE-2023-51767: a bogus CVE in OpenSSH
[Some people who received this message don't often get email from deraadt@...nbsd.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Damien Miller <djm@...drot.org> wrote:
> On Wed, 24 Sep 2025, Adiletta, Andrew wrote:
>
> > Hi Alexander and Team,
> >
> > Thank your for the interest in our paper, and we appreciate all the
> > feedback. We wanted to address two points - the OpenSSH CVE, and the
> > comments from the OpenSSH community about the practicality of the attack.
> >
> > On CVE-2023-51767 (OpenSSH), we did not submit this CVE. Our team
> > coordinates with vendors / software mantainers before submitting CVEs to
> > make sure there is agreement. The CVE description does seem
> > mischaracterized, as this is not a zero-click type vulnability as the CVE
> > suggests, and we would not oppose either a revision or other action. We did
> > work with Todd Miller on a SUDO CVE (CVE-2023-42465), of which we worked
> > with him to release a patch.
> >
> > However, on the practicality, I do believe that we did not mischaracterize
> > the attack in the paper, and as Alexander concisely mentioned, we are really
> > trying to emphasize the issues with simple 0/1 flag logic that leads down to
> > sensitive execution flows.
>
> Sure, but my criticism at the time was that your paper claimed in
> the abstract to have successfully attacked OpenSSH to bypass
> authentication but what was actually attacked was a modified version
> of sshd run in a highly unrealistic and synchronised setting.
>
> IMO this context matters and doesn't detract from your findings.
Andrew, I think you should answer Damien's comment.
I'm a bit more cynical, and think this is very close to open source
community engagement malpractice -- where you picked projects
specifically to increase readership of your paper, and went through the
effort to construct synthetic justification, and I think you should
consider issuing an official apology and/or official retraction of those
statements about OpenSSH being vulnerable. There you have it, that's my
opinion on this.
Content of type "text/html" skipped
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
