Re: When scrubbing secrets in memory doesn't work

[Gianni Tedesco <gianni () ecsc co uk>]

On Tue, 2002-11-05 at 22:13, Michael Howard wrote:
> 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."

FYI: tested on gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-112)
which doesn't seem to do this. What compiler version/flags, if any does
this depend on?

Should this optimisation actually even remove function calls? What if
you were depending on that function doing something? eg: writing
something to a file... I can understand with memset/memcpy or other
builtin functions because it could be hardcoded in the compiler to say
'allow optimiser to remove calls to this function' or whatever.

BTW. Are you suggesting that these bugs have appeared in the windows
kernel and/or related security applications? Obviously this could be
disastrous if the kernel allocates un-zeroed pages to userspace etc...
but I guess the kernel implementation would be hand-optimised inline
assembly or something anyway...

-- 
// Gianni Tedesco (College Flunky Supervisor)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

Attachment: signature.asc
Description: This is a digitally signed message part