[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cbd89f96-2958-4e5e-a7fe-5cf939a1140f@gmail.com>
Date: Mon, 22 Sep 2025 22:49:29 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com, Damien Miller <djm@...drot.org>
Cc: openssh@...nssh.com
Subject: Re: CVE-2023-51767: a bogus CVE in OpenSSH
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
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.
