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

[Jacob Bachmeyer <jcb62281 () gmail com>]

On 9/23/25 20:42, Adiletta, Andrew wrote:
> [...]
>
> However, on the practicality, I do believe that we did not 
> mischaracterize the attack in the paper, and as Alexander concisely 
> mentioned, we are really trying to emphasize the issues with simple 
> 0/1 flag logic that leads down to sensitive execution flows. Also, 
> great point about the exit codes, in hindsight that would've been a 
> good point to address as well. But ulimately, we did make 
> syncronization an assumption as stated in the paper, citing that there 
> are other teams working on syncronization methods 
> (https://www.usenix.org/conference/usenixsecurity22/presentation/aldaya 
> <https://www.usenix.org/conference/usenixsecurity22/presentation/aldaya>).

This seems to confirm my previous assessment that your attack from the 
paper is a proof-of-concept.

> Slight clarification on Peter's point - I agree with your point about 
> rad-hard faults protection on modern CPUs, although the threat model 
> for Mayhem was that registers, as a limited resource, need to 
> constantly swap back to DRAM, where register values can be corrupted 
> via Rowhammer and the corrupted values are then stored in the register 
> when they are brought back from DRAM.

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.


As I understand it, Rowhammer is a slow, probabilistic attack, 
requiring, at minimum, many milliseconds for a chance at success. If the 
target program is going to reload the values within microseconds, the 
probability of a successful attack rapidly approaches zero and there is 
no practical risk.  (A machine that vulnerable to Rowhammer is likely to 
flip too many bits in normal operation and crash so frequently that it 
gets replaced.)


This may point towards a previously-unrecognized security risk in OS 
schedulers, where delaying a privileged process is more than merely a 
denial-of-service.  Perhaps dynamic CPU affinities could be used to 
reduce the risk by reserving a core for privileged tasks when any are 
runnable?


Another solution could be a "scheduler yield" primitive that yields the 
processor but guarantees a full timeslice when the program is next 
resumed.  As long as the critical window can fit within a single 
scheduler timeslice, this would close the window on exploitation.

> From a hardware architectural standpoint, it might make sense to do a 
> hash check before and after register values are pushed and popped to 
> prevent this type of attack, but that was a bit out-of-scope for the 
> paper. But also, agree with your point on ECC as being a potentially 
> unreliable mitigation.

Any practical hash check will be no better than ECC:  the attacker need 
only also flip a few more bits.  Do not pretend that checksums are going 
to fix this.


If you think that a cryptographic digest is suitable for protecting 
register values spilled to the stack, then you have no idea how often 
registers are spilled and reloaded.



-- Jacob