Reposted.
> -----Original Message-----
> From: Michael Wojcik
> Sent: Wednesday, November 06, 2002 12:25 AM
> To: 'Michael Howard'
> Cc: [EMAIL PROTECTED]
> 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
>