Re: CVE-2023-51767: a bogus CVE in OpenSSH

[Jacob Bachmeyer <jcb62281 () gmail com>]

On 9/21/25 23:35, Damien Miller wrote:
> Hi,
>
> 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://arxiv.org/pdf/2309.02545
>
> 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.

I mostly agree---the platform is supposed to be coherent---but OpenSSH 
is a bit of a special case due to its position on a security boundary.

> 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.

The paper is *not* impressive, but may nonetheless have stumbled onto an 
actual problem.

If not for wanting to evaluate your complaint on the list, I would have 
stopped reading when they called the System V AMD64 ABI the 
"Intel-Ubuntu C convention" and %rsp "register stack pointer". (For 
anyone here who does not know: %rsp is just the "stack pointer"; x86 
registers have funny names for historical reasons and %esp now aliases 
the low-order 32 bits of %rsp while %sp (its original name on the 8086) 
now aliases the low-order 16 bits of %esp. The "e" and "r" are prefixes 
introduced with wider forms of the register file on the 80386 and AMD K8.)

Other fun mistakes in the paper include calling what are clearly DIMMs 
"chips" (in section 6) and what are clearly DIMM model numbers "serial 
numbers" (in table 1).

> 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.

Indeed they did, however the key for OpenSSH that will either prove the 
vulnerability bogus or point to solutions seems to be whether sshd will 
stop to read from the network during any of the potentially vulnerable 
periods.

If sshd blocks on read(2) while either of those flags are live, there is 
the potential for a local attacker to use SSH to escalate privileges. If 
not (and there is no other way for an unprivileged user to delay its 
execution), I agree that the CVE is bogus, for whatever that is worth.

> 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.

Part of their exploit involved "grooming" memory such that the kernel 
allocator will drop the "interesting" page in the new sshd process into 
the location where the attacker expects to be able to flip bits.

Interestingly, the researchers seem to have had more success exploiting 
the kernel allocator with OpenSSH than either sudo or OpenSSL, despite 
the viable set of "flippy" pages for the OpenSSH attack having 
intermediate size between the other two.  I suspect that sshd 
"re-rolling" ASLR may have a role here, since it means that each 
connection is a fresh chance for the needed victim page to land in the 
trap, but each run of sudo is also a new process.

A simple countermeasure might be to use alloca(3) for a random-size 
multi-page stack allocation (and zero it to force the pages to actually 
be allocated) during early initialization in main() to upset both the 
ordinal page number and the offset within the page of any "interesting" 
local variables in all other functions in sshd.

In short, ASLR is not enough when the kernel's allocation strategy can 
be exploited to drop the underlying physical page into the attacker's 
trap regardless of its randomized virtual address.

> 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.

While I agree that their attack is at best a proof-of-concept, I am not 
as certain yet that there is no possibility of someone else producing a 
viable attack, either as a local privilege escalation or a cross-VM 
attack in cloud environments.


-- Jacob