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

[Jacob Bachmeyer <jcb62281 () gmail com>]

On 9/26/25 20:04, Demi Marie Obenour wrote:
> On 9/26/25 20:06, Jacob Bachmeyer wrote:
> > On 9/26/25 09:19, Demi Marie Obenour wrote:
> > > On 9/25/25 22:33, Jacob Bachmeyer wrote:
> > > [...]
> > > > 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.
> > > Seehttps://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.
> > I am somewhat skeptical about this, simply because there have been many
> > "proper solutions" to Rowhammer that have thus far failed.
> Have any of them had a proof of correctness?  MOAT at least claims to,
> and if that proof is correct, then either it is secure or one of the
> assumptions it is based on is invalid.

Unless I misunderstood the paper on a first reading, that proof is only 
an upper bound on row activations before mitigations are applied.  That 
says *nothing* about actually preventing bit-flips.

In particular, the possibility of some as-yet-unknown access pattern not 
mitigated by MOAT being usable for Rowhammer is simply out-of-scope for 
MOAT's correctness proof---and disturbingly plausible to me as DRAM 
densities continue to increase.

> > > > [...]
> > > >
> > > >
> > > > 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.
> > You suspect that ASLR is generally provably useless?  "Sliding" the
> > stack is the same basic principle as ASLR.
> ASLR is an awesome mitigation.  It definitely makes attacks much harder.
> I have yet to see a case where it provably makes an attack impossible.
> If you are aware of one, I would love to know.

Provably impossible?  No, but it *can* increase the number of bits that 
an attacker must accurately guess beyond feasibility.

> > The "Rowhammer Mayhem" attack evades ASLR by exploiting the kernel's
> > physical page allocation policy, effectively converting the significant
> > address to an ordinal page number ("Nth page allocated") and offset
> > instead of a virtual or physical address.
> >
> > > My hope is that
> > > EU regulations like CRA and PLD will force hardware recalls when defects
> > > like Rowhammer are detected.
> > You realize that legal cudgels like that could very well kill the entire
> > computing industry if it turns out that Rowhammer is due to physical
> > limitations, right?
> There is no law saying that DRAM must be used, or that it must have
> a feature size as small as it has.  A larger feature size (bigger
> capacitors) could stop the attack, albeit at great expense.
> Increasing the refresh rate and noise margins would also help.

Both of those are effectively mandated by the marketplace and current 
technology.  DRAM is the only currently practical ultra-high-density 
fast working memory technology, and the small feature sizes are needed 
both for capacity and performance.

It is not just a matter of "great expense"---bigger DRAM capacitors also 
mean *slower* DRAM. The laws of physics are not subject to repeal or 
revision to suit our wants.

> Another option is to cryptographically authenticate every row.  If
> a full-width MAC is used, the attacker must flip at least 129 bits
> and they have absolutely no margin for error: even a single error
> will be detected.  If the attacker cannot do this (and I have seen
> no paper suggesting they can), this prevents Rowhammer from being
> a memory corruption vulnerability.  If the memory is also encrypted,
> this reduces Rowhammer to denial of service at worst.  DRAM rows
> are very wide, so the cost of the MAC can be amortized across a
> large number of bits.

Computing a cryptographically-sound MAC is very expensive, although 
using an authenticated encryption mode with existing hardware RAM 
encryption could help.  Even RAM encryption at all might help, if a 
non-malleable mode is used, since then flipping one ciphertext bit will 
cause multiple plaintext bits to flip.

> The burden should be on hardware vendors to create hardware without
> security holes.  Formal verification at the HDL level can catch
> defects in the source code.  Some proofs might be able to be
> generated automatically, while others might have to be written by
> hand and machine-checked.  For other issues, there is no solution
> I know of other than being extremely careful in the design process.

Rowhammer relies on physical effects that are not normally modeled in 
VLSI design and may or may not be sufficiently characterized to 
predictively model.  As far as I know, the DRAM vendors are not talking 
about those details.

Further, normal programs do not make the access patterns that cause 
Rowhammer bit flips.  The hardware is arguably working correctly when 
used as intended and not actually defective.  On modern hardware, a 
normal program frequently accessing the same row should hit DRAM once 
and then the caches.  Rowhammer attacks arrange fake working sets that 
exceed the caches and produce highly unusual access patterns.

> If defects like Rowhammer, Zenbleed, or Spectre forced product
> recalls, there would be a massive economic incentive to produce
> hardware that lacked such defects.  I suspect this would solve the
> problem in fairly short order.  The question is whether the
> economic cost of doing so -- and of not doing so -- is something
> that society, and end users, are willing to pay.

You realize that between Zenbleed and Spectre, *both* current x86 
processor vendors would likely now be bankrupt due to expensive recalls 
if your proposal had been adopted?  Where would that leave us?  With 
other CPU architectures?  Well, then...

Rowhammer affects basically the entire DRAM industry.  What would be the 
economic results of an industry-wide recall?  Would the recall simply be 
ignored because users prefer to actually *have* computers?

I suspect that the result of such EU policies would be the industry 
leaving the EU market.


-- Jacob