Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Dan Kaminsky (dan_at_doxpara.com)
Date: Wed Oct 30 2002 - 12:00:00 CST
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.