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

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

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.

> 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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature