Re: A Famous Security Bug

On 3/21/2024 10:41 AM, Kaz Kylheku wrote:

On 2024-03-21, David Brown <david.brown@hesbynett.no> wrote:

On 20/03/2024 19:54, Kaz Kylheku wrote:

On 2024-03-20, Stefan Ram <ram@zedat.fu-berlin.de> wrote:

    A "famous security bug":
>
void f( void )
{ char buffer[ MAX ];
    /* . . . */
    memset( buffer, 0, sizeof( buffer )); }
>
    . Can you see what the bug is?

>
I don't know about "the bug", but conditions can be identified under
which that would have a problem executing, like MAX being in excess
of available automatic storage.
>
If the /*...*/ comment represents the elision of some security sensitive
code, where the memset is intended to obliterate secret information,
of course, that obliteration is not required to work.
>
After the memset, the buffer has no next use, so the all the assignments
performed by memset to the bytes of buffer are dead assignments that can
be elided.
>
To securely clear memory, you have to use a function for that purpose
that is not susceptible to optimization.
>
If you're not doing anything stupid, like link time optimization, an
external function in another translation unit (a function that the
compiler doesn't recognize as being an alias or wrapper for memset)
ought to suffice.

>
Using LTO is not "stupid".  Relying on people /not/ using LTO, or not
using other valid optimisations, is "stupid".

 LTO is a nonconforming optimization. It destroys the concept that
when a translation unit is translated, the semantic analysis is
complete, such that the only remaining activity is resolution of
external references (linkage), and that the semantic analysis of one
translation unit deos not use information about another translation
unit.
[...]

Side note:
Actually, way back (pre c/c++ 11), I was worried about LTO messing up my custom, highly sensitive sync code.
https://web.archive.org/web/20070509044340/http://appcore.home.comcast.net/
Notice the externally assembled functions comment?
"All of its “critical-sequences” are contained in externally assembled functions ( read all ) in order to prevent a rouge C compiler from reordering anything that would corrupt the data-structure. The queue allocates its nodes from a three-level cache"
If a damn "rogue" compiler can mess with my custom ASM then things are going to be broken...
;^)