[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <607fcfda-ab5f-4a9a-a341-2a9e2beede20@gmail.com>
Date: Fri, 26 Sep 2025 21:04:08 -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/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.
>> 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.
>
> 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.
>>> [...]
>>>
>>>
>>> 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.
> 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.
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.
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.
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.
--
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.
