Bugtraq mailing list archives

Re: When scrubbing secrets in memory doesn't work


From: Nicholas Weaver <nweaver () CS berkeley edu>
Date: Sun, 17 Nov 2002 08:49:28 -0800

On Thu, Nov 14, 2002 at 02:44:58AM -0800, Michael Wojcik composed:
Scrubbing is clearly no more than a best-effort attempt to make it more
difficult to retrieve sensitive data from memory.  I think it's of dubious
value, frankly, and this thread has probably prompted more discussion than
it warrants.  There is a portable way to prevent the dead-store-elimination
problem, but that's only one of scrubbing's many failings.

This seems like a huge amount of pushing-on-a-rope, trying to do
things which the compilers don't like to do, and really aren't
supposed to do, as people are asking for semantic effects which aren't
part of the language specs.

A trivial observation: If the attacker can read your memory, you are
in deep trouble.  All scrubbing does is limit the window of
observation for being just the time the data is live, instead of until
the memory page is reallocated and blanked by the OS.

A second observation: If you really want this behavior, replace/tweak
malloc/free!  Free, being a library routine, tend to be outside the
scope of the compiler's optimizaion.  If free blanks memory in the
process, you now don't have to worry about scrubbing.  You could add a
malloc variant which says "block X should be scrubbed on freeing", if
you needed more efficiency.

The bigger concern is when the memory is paged to disk, and that
record may have a much MUCH longer time window.  But scrubbing has no
real effect on this, this is an effect of VM memory management and
memory-only pinning.

-- 
Nicholas C. Weaver                                 nweaver () cs berkeley edu


Current thread: