Nicholas Weaver wrote:
On Thu, Nov 14, 2002 at 02:44:58AM -0800, Michael Wojcik composed:
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
On Mon, Nov 18, 2002 at 04:36:57PM +, Richard Moore wrote:
> Nicholas Weaver wrote:
> > On Thu, Nov 14, 2002 at 02:44:58AM -0800, Michael Wojcik composed:
> > 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
Richard Moore <[EMAIL PROTECTED]> writes:
> It's worth noting that on systems such as linux and solaris, it is
> easy to avoid the paging problem by locking the process into
> memory.
"Locking into memory" does NOT mean "avoid paging". AFAIK, there are
operating systems in which memory which has
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
> From: Jan Echternach [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 11, 2002 11:47 AM
> On Fri, Nov 08, 2002 at 05:23:34PM +0100, Michael Zimmermann wrote:
> > Not to declare the intermediate storage for sensitive
> > data as 'volatile' is a coding flaw. An esily overlooked
> > one, yes, bu
On Fri, Nov 08, 2002 at 05:23:34PM +0100, Michael Zimmermann wrote:
> Not to declare the intermediate storage for sensitive
> data as 'volatile' is a coding flaw. An esily overlooked
> one, yes, but nevertheless... Like forgetting to protect
> critical code with semaphores.
'volatile' isn't suffic
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 [mai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At Dienstag, 5. November 2002 23:13 Michael Howard wrote:
> During the Windows Security Push in Feb/Mar 2002, we noticed an
> 'interesting' anomaly with code to scrub passwords that looks like this:
>
> bool DoSensitiveStuff() {
> bool fOK = fals
During the Windows Security Push in Feb/Mar 2002, we noticed an
'interesting' anomaly with code to scrub passwords that looks like this:
bool DoSensitiveStuff() {
bool fOK = false;
const size_t cbPwd = 64;
char szPwd[cbPwd];
if (GetUserPassword(szPwd,cbPwd-1))
On Wed, 06 Nov 2002 12:55:26 GMT, Gianni Tedesco <[EMAIL PROTECTED]> said:
> FYI: tested on gcc version 2.96 2731 (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?
gcc 3 and later (3.2 is current) are well able to do this
> > 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 m
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.
>
"Michael Howard" <[EMAIL PROTECTED]> writes:
> 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.
Thats
During the Windows Security Push in Feb/Mar 2002, we noticed an
'interesting' anomaly with code to scrub passwords that looks like this:
bool DoSensitiveStuff() {
bool fOK = false;
const size_t cbPwd = 64;
char szPwd[cbPwd];
if (GetUserPassword(szPwd,cbPwd-1))
14 matches
Mail list logo
