BugTraq
When scrubbing secrets in memory doesn't work Nov 05 2002 10:13PM
Michael Howard (mikehow microsoft com) (3 replies)
Re: When scrubbing secrets in memory doesn't work Nov 08 2002 04:23PM
Michael Zimmermann (zim vegaa de) (1 replies)
Re: When scrubbing secrets in memory doesn't work Nov 11 2002 11:46AM
Jan Echternach (jan goneko de)
Re: When scrubbing secrets in memory doesn't work Nov 06 2002 12:55PM
Gianni Tedesco (gianni ecsc co uk) (1 replies)
Re: When scrubbing secrets in memory doesn't work Nov 08 2002 04:00AM
Valdis Kletnieks vt edu
Re: When scrubbing secrets in memory doesn't work Nov 05 2002 11:58PM
Perry E. Metzger (perry piermont com) (1 replies)
Re: When scrubbing secrets in memory doesn't work Nov 07 2002 08:08AM
Andy Polyakov (appro fy chalmers se)
> > On the surface, this looks fine, until you look at the ASM output, and
> > you see the call to memset has been removed by the optimizer because
> > szPwd is not read once the function completes. Hence, the secret data is
> > still floating in memory.
> >
> > This optimization, common in most modern C/C++ compilers is often
> > referred to as "dead store removal."

Among a variety of tested compilers GCC>=3, SGI MIPSpro, and Microsoft
compilers were the only ones that actually eliminated the [inlined]
memset. Others preserved the inlined code [or call to memset for that
matter] at all optimization levels.

> Thats why you have to declare such data volatile -- to prevent
> optimizers from becoming too anxious to help.

Caveat lector! Both MIPSpro and Microsoft compilers effectively
ignore "volatilization" of pPwd. I mean even if you declare pPwd in
their example volatile, these two compilers still happily eliminate
the inlined memset, because volatile qualifier gets discarded at
"invocation" of memset [which compiler warns you about]. GCC>=3 is
apparently the only one that respects "volatilization" of pPwd.

It should also be noted that if you attempt to apply the first
workaround suggested my Michael Howard ("Touch secret data"), MIPSpro
and GCC>=3 nullify only the first byte of pPwd and leave the rest
intact!

The only thing that seem to work [on all affected platforms] is own
implementation of memset with internal "volatilization" of first
argument (second workaround proposed by Michael Howard):

void *guaranteed_memset(void *v,int c,size_t n)
{ volatile char *p=v; while (n--) *p++=c; return v; }

which is safe at any optimization level [even if gets inlined].

Bottom line. "Volatilization" is indeed the answer, but it has to be
used in right place.

Cheers. A.

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus