Re: A Famous Security Bug

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.