RE: Software leaves encryption keys, passwords lying around in memory

["Dom De Vitto" <dom () DeVitto com>]

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:dom () devitto com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 


-----Original Message-----
From: Dan Kaminsky [mailto:dan () doxpara com] 
Sent: Wednesday, October 30, 2002 6:00 PM
To: Peter Gutmann
Cc: vuln-dev () securityfocus com
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