Hi, I recently received this email from the Bugtraq mailing list, and was wondering if it was relevant to OpenSSL. I checked the README and INSTALL files from version 0.9.6g and there doesn't appear to be anything relevant.
Regards, Adrian ----- Original Message ----- From: Michael Wojcik <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 12, 2002 4:07 PM Subject: RE: When scrubbing secrets in memory doesn't work > 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 > > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
