Well well, if it ain't the hacker who just won't let data die...

>int encrypt( const void *key )
> {
> puts( key ); /* Normally we'd encrypt here */
> }
>
>void main( void ) /* Because we can */
> {
> char key[ 16 ];
>
> strcpy( key, "secretkey" );
> encrypt( key );
> memset( key, 0, 16 );
> }
>
>When compiled with any level of optimisation using gcc, the key clearing call
>goes away because of dead code elimination
>
Compilers getting too smart? Introduce runtime dependancies, then.

Instead of dumping compile-time values into RAM, suck something the
compiler can't predict -- system clock, non-const variables, runtime
seeded rc4, whatever. Then run some conditional based off the entire
output and have it do some trivial syscall, like a 1 vs. 2ns nanosleep.

Except for a precious few exceptions at time of process death, with
compilers executing optimizations by some form of pointer-renaming in
which a memory address at one time may be exchanged with a memory
address at another (certainly imaginable in a couple obscure
NUMA/transparent distributed memory architectures)...it would seem
provably impossible for any compiler to optimize away the memory
overwrite and still create a valid representation of the code.

Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]