[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dac51d5e-e9a9-4e8d-b044-7da3316c9252@gmail.com>
Date: Fri, 26 Sep 2025 10:19:09 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: jcb62281@...il.com, oss-security@...ts.openwall.com,
Peter Gutmann <pgut001@...auckland.ac.nz>,
"Adiletta, Andrew" <ajadiletta@....edu>, Solar Designer
<solar@...nwall.com>, Andrew Cooper <andrew.cooper3@...rix.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/25/25 22:33, Jacob Bachmeyer wrote:
> On 9/25/25 14:38, Demi Marie Obenour wrote:
>> On 9/24/25 23:51, Jacob Bachmeyer wrote:
>>> 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.
>> What about hardware fixes? Those will take a long time
>> to roll out but hopefully they can be 100% effective.
>
> First, that does absolutely nothing for current hardware. Declaring all
> (or almost all) current hardware e-waste is severely environmentally
> irresponsible if it can possibly be avoided.
I don't know that it can be.
> Second, I had expected ECC to "kill Rowhammer dead" only to find that it
> can be possible to cause enough bit flips to get all the way from one
> valid ECC word to another valid ECC word before ECC scrub reaches the
> location. I suspect that the DDR5 built-in ECC is supposed to resolve
> Rowhammer, but we will have to wait and see if it actually achieves that
> goal.
>
> It seems highly likely that Rowhammer is an inherent consequence of DRAM
> density beyond a certain limit and highly *unlikely* that reducing DRAM
> density below the "Rowhammer threshold" will prove to be an acceptable
> solution.
See https://arxiv.org/pdf/2407.09995 for the proper solution: store a
per-row activation counter alongside the row itself, and when any row
in a bank exceeds the threshold, take action.
>>> 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.
>> One idea I had is to add physical guard pages
>> between uses of memory for different purposes.
>
> That depends on assumptions about physical layout that may not hold.
> (What if the DRAM is interleaved such that the guard pages end up in a
> different bank or chip?) Apparently the researchers already had to hit
> areas at some logical distance from the target; I doubt that the exact
> physical DRAM layout in the chips they used is published.
>
> Worse, skipping page frames like this may work for one DRAM density and
> silently fail for another, or even between two different chips with the
> same density but different internal layouts, or even between identical
> hardware that has different memory controller configurations for some
> reason.
>
>
> The stack is intrinsically aligned on much finer than page granularity;
> introducing additional "jitter" to the locations of stack variables (and
> spilled registers) is a solution available today with minimal cost. All
> you need is "size_t slide_size=random_stack_slide_size(); void *
> slide=alloca(slide_size); memset(slide,0,slide_size);" near the top of
> main (and possibly other functions to "mix it up" more) and a function
> random_stack_slide_size() that gives an appropriate unpredictable value.
>
> The key is to avoid trying to prevent bits from being flipped (that
> proverbial ship has sailed on current hardware) but instead prevent an
> attacker from being able to predict accomplishing something useful with
> those bit-flips.
I suspect that in general this is provably impossible. My hope is that
EU regulations like CRA and PLD will force hardware recalls when defects
like Rowhammer are detected.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
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.
