[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0ea3da20-739e-4608-8869-9d5882a8f003@gmail.com>
Date: Wed, 24 Sep 2025 22:51:56 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: Peter Gutmann <pgut001@...auckland.ac.nz>,
"oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>,
"Adiletta, Andrew" <ajadiletta@....edu>, Solar Designer <solar@...nwall.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>
Subject: Re: Re: [EXT] Re: CVE-2023-51767: a
bogus CVE in OpenSSH
On 9/24/25 06:45, Peter Gutmann wrote:
> Jacob Bachmeyer <jcb62281@...il.com> writes:
>
>> The critical issue for exploiting Rowhammer to corrupt spilled register
>> values seems to be how long those spilled values remain live in DRAM before
>> they are reloaded into the register file and ultimately used.
> It also depends on whether they're ever actually read back from RAM or just
> end up sitting in cache for a microsecond or two before they're re-fetched
> from there. There are some attacks that exploit the difference between
> (glitched) data in RAM and data in cache, but in this case it'd mitigate
> Rowhammer by having the corrupted data in RAM ignored if it's still in cache.
Indeed, if the spilled value is never evicted from cache, then it is
never live in DRAM and Rowhammer cannot be used to corrupt it. However,
if I understand correctly, modern systems aggressively flush caches on
process context switches in order to close cache-related side channels.
This seems to suggest that the solution to "Rowhammer Mayhem" may lie in
improvements to kernel scheduler and VM management subsystems.
Perhaps a yield primitive that yields the rest of the current timeslice
but guarantees a full unpreemptable timeslice upon resume? That would
allow a brief sensitive computation to be effectively made
uninterruptible but would not permit monopolization of the processor.
Perhaps more randomization in assigning physical page frames to prevent
the kernel from reliably using "bait" pages? The attack in the paper
seems to depend on predictable page frame allocation.
The latter could also be implemented in user processes: allocate a
randomly-sized pad on the stack to shift "inner" stack variables away
from their predictable locations. Making the pad multiple pages plus a
fraction of a page could also counter predictable kernel page frame
allocations by shifting the sequence of pages allocated.
-- Jacob
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.
