Re: Re: [EXT] Re: [oss-security] CVE-2023-51767: a bogus CVE in OpenSSH

[Demi Marie Obenour <demiobenour () gmail com>]

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 () gmail 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)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature