[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<BL1PR01MB772308134BF946DF07159A05C11CA@BL1PR01MB7723.prod.exchangelabs.com>
Date: Wed, 24 Sep 2025 01:42:11 +0000
From: "Adiletta, Andrew" <ajadiletta@....edu>
To: Solar Designer <solar@...nwall.com>, "oss-security@...ts.openwall.com"
<oss-security@...ts.openwall.com>
CC: "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
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. Also, great point about the exit codes, in hindsight that would've been a good point to address as well. But ulimately, we did make syncronization an assumption as stated in the paper, citing that there are other teams working on syncronization methods (https://www.usenix.org/conference/usenixsecurity22/presentation/aldaya).
Slight clarification on Peter's point - I agree with your point about rad-hard faults protection on modern CPUs, although the threat model for Mayhem was that registers, as a limited resource, need to constantly swap back to DRAM, where register values can be corrupted via Rowhammer and the corrupted values are then stored in the register when they are brought back from DRAM. From a hardware architectural standpoint, it might make sense to do a hash check before and after register values are pushed and popped to prevent this type of attack, but that was a bit out-of-scope for the paper. But also, agree with your point on ECC as being a potentially unreliable mitigation.
Thanks,
Andrew Adiletta
________________________________
From: Solar Designer <solar@...nwall.com>
Sent: Monday, September 22, 2025 11:21 PM
To: oss-security@...ts.openwall.com <oss-security@...ts.openwall.com>
Cc: openssh@...nssh.com <openssh@...nssh.com>; Tol, Caner <mtol@....edu>; Adiletta, Andrew <ajadiletta@....edu>; Sunar, Berk <sunar@....edu>; Doroz, Yarkin <ydoroz@....edu>; Todd C. Miller <Todd.Miller@...rtesan.com>
Subject: [EXT] Re: [oss-security] CVE-2023-51767: a bogus CVE in OpenSSH
[You don't often get email from solar@...nwall.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi Damien and the OpenSSH team,
Thank you for bringing this up, and sharing your stance on this issue so
clearly and comprehensively.
Below are some extra thoughts and questions. I am not arguing with your
judgment here; I actually agree with you.
On Mon, Sep 22, 2025 at 02:35:08PM +1000, Damien Miller wrote:
> A few people have asked about CVE-2023-51767, which proportedly is an
> "authentication bypass via row hammer attack" in OpenSSH sshd. This
> CVE is bogus.
>
> It is based on this paper "Mayhem: Targeted Corruption of Register and
> Stack Variables" by Adiletta, et al.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fpdf%2F2309.02545&data=05%7C02%7Cajadiletta%40wpi.edu%7Ca3c5e8fcba3345716db608ddfa504702%7C589c76f5ca1541f9884b55ec15a0672a%7C0%7C0%7C638941944921836508%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I9wSLHhQOXpjCGcNeOrsHbZ5W50sWqqP4dkniRrUthk%3D&reserved=0<https://arxiv.org/pdf/2309.02545>
FWIW, this paper was brought to oss-security back then, and I've added
CC's to this reply based on that message:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openwall.com%2Flists%2Foss-security%2F2023%2F12%2F21%2F9&data=05%7C02%7Cajadiletta%40wpi.edu%7Ca3c5e8fcba3345716db608ddfa504702%7C589c76f5ca1541f9884b55ec15a0672a%7C0%7C0%7C638941944921860929%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RhEnpVl2Yl43FbChVtRV0Znnj7F1%2FJQBbBpgXBy3n6I%3D&reserved=0<https://www.openwall.com/lists/oss-security/2023/12/21/9>
The only CVE I see in the paper itself is CVE-2023-42465 for sudo, which
upstream (and some distros) fixed. Was it perhaps more serious for sudo
(actually exposed in real-world setups)? Also CC'ing Todd for sudo.
> Firstly, we do not consider it to be the application's responsibility
> to defend against platform achitectural weaknesses. We're happy
> to adopt platform measures (e.g. toolchain defences) where it is
> possible to do so, but fundamentally it is the platform's job to
> provide a coherent execution environment. If we collectively start to
> blame applications for platform failures, then there would be little
> end to the redundant defensive checks applications would need to
> implement.
Perhaps the way is to assign one CVE per platform weakness, which
applications may then refer to as providing hardening against. In this
case, Mayhem could get one CVE.
We similarly have shared CVEs for some protocol issues, e.g. many
projects are happily referring to one shared CVE for the HTTP/2
"MadeYouReset" DoS attack:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openwall.com%2Flists%2Foss-security%2F2025%2F08%2F16%2F1&data=05%7C02%7Cajadiletta%40wpi.edu%7Ca3c5e8fcba3345716db608ddfa504702%7C589c76f5ca1541f9884b55ec15a0672a%7C0%7C0%7C638941944921882666%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ny2Cqq9KiystY9gjPRTi4%2FM3ZFVRMXVbIaM47Uwr%2BHg%3D&reserved=0<https://www.openwall.com/lists/oss-security/2025/08/16/1>
Some others got their own CVEs for their instances of the problem, but
they didn't have to.
> On this attack specifically, the paper claims "We demonstrate the
> power of the findings by applying the techniques to bypass SUDO
> and SSH authentication", but they appear to have achieved this in
> only highly contrived and unrealistic circumstances where they have
> either modified the software under test or run the attack with root
> privileges to dramatically simplify the attack.
>
> Per section 6.1 - "we used signals to make sure the programs were
> synchronised". However, it is not possible to signal a privileged
> process without the attacker already holding privilege on the
> target system. An attack that requires root privileges to attack a
> root-privileged process isn't a demonstration of a vulnerability.
>
> It appears the researchers need this additional synchronisation
> to both grow the window in which the variable was available for
> attack and to arrange the physical memory layout to be in a known
> and attackable configuration (section 4.1). This too is unrealistic
> in the context of sshd, where each connection is handled by a
> separately-executed sshd process, with a completely unique address
> space. Again, fine control over the address space of the sshd process
> (such as that suggested by section 4.1) can only be exerted with
> preexisting privilege by the attacker.
This sounds convincing.
> This attack is not feasible under conditions remotely approximating
> the real world. It certainly doesn't warrant a CVSS score of 7.0 and
> in my opinion no CVE should have been issued at all for it.
CVSS base score is generally a poor indicator of overall severity of a
vulnerability as it mostly considers attack vector and risk impact, but
not risk probability.
> We communicated our concern that the researchers were overstating
> their findings when we were informed of this work, but this feedback
> was not reflected in the final paper or in the subsequent CVE.
>
> Unfortunately, at no stage of the CVE issuance process was OpenSSH
> contacted about this advisory either. This seems pretty suboptimal as
> a process.
>
> Posting this for the record and in the hope that someone will help
> get the CVE disputed.
Red Hat CNA offered help with this further in the thread, so I hope it
will be taken care of.
CVEs and process aside, I do find the Mayhem research exciting, even if
not applicable in the real world in this specific instance.
I also worry about risk of software bugs that a simple 0/1 flag may be
more susceptible to than e.g. magic values would be. Maybe we can
identify a reasonable level of defensive programming without going for
slippery slope ("little end to the redundant defensive checks", as you
correctly write) and without slapping CVEs on applications.
I am especially concerned about process exit codes used to decide on
granting or denying access. This is why we use 32-bit magic values in
pam_tcb communication with its helper program tcb_chkpwd (since 2002 if
not earlier). I am concerned that upstream Linux-PAM pam_unix
communication with its unix_chkpwd relies on the exit code alone. Not
so much because it may be an attractive target for Mayhem (I am
surprised the paper does not mention process exit codes?) but primarily
because some other system component (perhaps a library or the kernel)
may also trigger a process exit with some code (and there are only 256
to choose from). That would be a vulnerability introduced by that other
component (and so a CVE against it), but the effect is the same.
Thanks again,
Alexander
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.
