RE: When scrubbing secrets in memory doesn't work

[Michael Wojcik <Michael.Wojcik () microfocus com>]

Reposted.

> -----Original Message-----
> From: Michael Wojcik 
> Sent: Wednesday, November 06, 2002 12:25 AM
> To: 'Michael Howard'
> Cc: bugtraq () securityfocus com
> Subject: RE: When scrubbing secrets in memory doesn't work
>
>
> > From: Michael Howard [mailto:mikehow () microsoft com]
> > Sent: Tuesday, November 05, 2002 5:13 PM
>
> > [memset doesn't always]
>
> I don't know if you followed the discussion on Vuln-dev after 
> Peter Gutmann mentioned your article, 30-31 October, but Dom 
> De Vitto[1] and I both described ways of avoiding this 
> problem that work on any conforming C90/94/99 
> implementation[2].  Pavel Kankovsky[3] and I both noted that 
> De Vitto's simple suggestion of using the "volatile" 
> sc-specifier should sufficient for any conforming C 
> implementation, at least as we read the standards (and with 
> the caveat that passing a volatile-qualified pointer to 
> memset may not be valid, so assignment might have to be done 
> manually), though I prefer the "external memset" approach for 
> various reasons[4].  Dan Kaminsky makes the general point 
> that introducing dependencies that can only be evaluated at 
> run time also does the trick[5], though that's generally more 
> work than the simple "volatile" and "external memset" solutions.
>
> In sum, this is not a particularly interesting problem.  It's 
> useful to have it pointed out (and we might have hoped that 
> the authors of security-sensitive software would be more 
> familiar with optimization techniques, the language 
> standards, and what might happen to this kind of application 
> of memset), and the maintainers of code that handles 
> passwords should check for and correct it, but contra Peter 
> Gutmann it does not appear to be a hard problem to solve, nor 
> need solutions be necessarily implementation-specific.
>
> Of the solutions given in your article, all should work on 
> your implementation, but the first:
>
>       memset(ptr, 0, len);
>       (volatile char *)ptr[0] = (volatile char *)ptr[1];
>
> is clearly preferable as it is portable.  (I think - that 
> lvalue cast may not be legal, actually.  Or, for that matter, 
> casting on volatility.  I'd have to check.)
>
> It's worth noting that I believe the standard *still* allows 
> a conforming implementation to skip the memset in the case of 
> your first solution, too.  Because the pointer being passed 
> to memset is not itself volatile-qualified, the 
> implementation can apply the "as if" rule - the generated 
> code need only behave *as if* following the rules of the 
> abstract machine, provided all side effects visible to the 
> program are maintained.  (That's a gloss, not language taken 
> directly from the standard, but it's the basic idea.)  A 
> clever optimiser could note that it is only necessary that it 
> perform the volatile read and write in the second line.
>
> So that's not a portable solution either, actually.  My 
> advice: use an external memset wrapper.  Simple, safe, portable.
>
> 1. http://makeashorterlink.com/?A5C922B52
> 2. http://makeashorterlink.com/?E50A12B52
> 3. http://makeashorterlink.com/?J11A62B52
> 4. http://makeashorterlink.com/?H32A23B52
> 5. http://makeashorterlink.com/?T1A924B52
>
> Michael Wojcik
> Principal Software Systems Developer, Micro Focus