[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SY8P300MB0711638E26D2EA3CE5E0ED7AEE1DA@SY8P300MB0711.AUSP300.PROD.OUTLOOK.COM>
Date: Tue, 23 Sep 2025 12:36:45 +0000
From: Peter Gutmann <pgut001@...auckland.ac.nz>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
CC: "openssh@...nssh.com" <openssh@...nssh.com>, "Tol, Caner" <mtol@....edu>,
"Adiletta, Andrew" <ajadiletta@....edu>, "Sunar, Berk" <sunar@....edu>,
"Doroz, Yarkin" <ydoroz@....edu>, "Todd C. Miller"
<Todd.Miller@...rtesan.com>
Subject: Re: CVE-2023-51767: a bogus CVE in OpenSSH
Solar Designer <solar@...nwall.com> writes:
>I also worry about risk of software bugs that a simple 0/1 flag may be more
>susceptible to than e.g. magic values would be. Maybe we can identify a
>reasonable level of defensive programming without going for slippery slope
You can write code that deals with bit-flips (SEEs to use the correct term)
and the like but you pretty much need to do it end-to-end if you're worried
about real-world bit-flips, and that's a *lot* of work. If you want the full
gory details:
https://www.cs.auckland.ac.nz/~pgut001/pubs/software_faults.pdf
To answer a question from another post, ECC RAM won't necessarily help you
because you can get faults like word-line upsets that ECC won't detect, I've
got a second talk that covers that if anyone's interested. The upside is that
most modern desktop/ server processors are essentially rad-hard so faults in
the CPU or data in on-CPU cache memory aren't so much a concern any more.
Peter.
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.
