Re: When scrubbing secrets in memory doesn't work

[Jan Echternach <jan () goneko de>]

On Fri, Nov 08, 2002 at 05:23:34PM +0100, Michael Zimmermann wrote:
> Not to declare the intermediate storage for sensitive
> data as 'volatile' is a coding flaw. An esily overlooked
> one, yes, but nevertheless... Like forgetting to protect
> critical code with semaphores.

'volatile' isn't sufficient to be safe.  In fact, there's no way to be
sure that some C code doesn't leave copies of sensitive data around,
because there's nothing in the C standard that forbids the compiler to
keep copies of data.  'volatile' only forbids certain usages of that
data (provided that the implementation defined aspects of 'volatile'
are defined in a sane way).

Typical examples of such copies are temporary data while evaluating
expressions, and copies of processor registers on the stack that are often
required by the ABI.

For example, take gcc-3.0.4 on Linux/ix86, optimizations turned off,
and the following code:

| #include <stddef.h>
| extern void zero (volatile void *, size_t);
| void foo3 (volatile unsigned long *keyl,
|         volatile unsigned long *keyr)
| {
|         volatile unsigned long keyx;
|         keyx = (*keyl + *keyr) * (*keyl - *keyr)
|            - (*keyl ^ *keyr) * (~*keyl * ~*keyr);
|         bar3 (&keyx);
|         zero (&keyx, sizeof keyx);
| }

It's compiled to this assembly code (only a small snippet before the
call to bar3()):

|         movl    %ebx, %eax
|         movl    %eax, -8(%ebp)
|         subl    $12, %esp
|         leal    -8(%ebp), %eax
|         pushl   %eax
|         call    bar3

The value of keyx is in register %ebx.  If bar3() uses %ebx internally
(which it probably does if it is non-trivial), the first thing after
setting up the stack frame will be saving the old value of %ebx
(i.e. keyx) on the stack.

-- 
Jan                           fortune: can't load library '/libc.so.4'
                                      No such library.