volatile char key[ 16 ]; (== don't optimise access to/from this var in any way) end of problem. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:domat_private - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -----Original Message----- From: Dan Kaminsky [mailto:danat_private] Sent: Wednesday, October 30, 2002 6:00 PM To: Peter Gutmann Cc: vuln-devat_private Subject: Re: Software leaves encryption keys, passwords lying around in memory 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
This archive was generated by hypermail 2b30 : Wed Oct 30 2002 - 11:58:45 PST