Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Fri, 22 Mar 2024 07:50:09 -0700
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <86a5mql3ry.fsf@linuxsc.com>
References: <bug-20240320191736@ram.dialup.fu-berlin.de> <20240320114218.151@kylheku.com> <20240321211306.779b21d126e122556c34a346@gmail.moc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="43a124101bc8549bfa1c6f6d248b1944";
	logging-data="3141256"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1820LYTj/yTSHX3OWUKPF+l4wR8VICgcHY="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:NNCA3xQMDidJNyDxurVMurgs6WQ=
	sha1:uVu21fcn+FBQ9HeJ9f9TqOySLmQ=
Bytes: 3601

Anton Shepelev <anton.txt@gmail.moc> writes:

> Kaz Kylheku to Stefan Ram:
>
>>>>   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.
>
> I think this behavior (of a C compiler) rather stupid.  In a
> low-level imperative language, the compiled program shall
> do whatever the programmer commands it to do.  If he
> commands it to clear the buffer, it shall clear the buffer.
> This optimisation is too high-level, too counter-inituitive,
> even deceitful.  The optimiser is free to perform the task
> in the fastest manner possible, but it shall not ignore the
> programmer's order to zero-fill the buffer, especially
> without emitting a warning about (potentially!) redundant
> code, which it is the programmer's reponsibility to confirm
> and remove.
>
> Redundant code shall be dealt with in the source, rather than
> in the executable.

I have a couple of reactions.

One is that the ship has sailed.  Somewhere between 35 and 40
years ago the people who wrote the C standard decided on a
semantic model that allows optimizations like this, and that is
not going to change.  Certainly there are people who would prefer
to think of C as being a "low-level imperative language" like
what you describe, but the C community as a whole has accepted
the view taken by the authors of the C standard.

The second reaction is that, to be somewhat blunt, what is being
suggested is naive.  I expect you do not yet appreciate the
ramifications of what you are suggesting.  It is hard, indeed I
would say very hard, to define a semantic model that faithfully
represents the behaviors you would like to impose.  You might
want to look into that, and what has been tried previously along
these lines, before pursuing this advocacy any further.