Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: When scrubbing secrets in memory doesn't work
From: Peter Watkins <peterw () usa net>
Date: Mon, 18 Nov 2002 13:19:38 -0500

On Mon, Nov 18, 2002 at 04:36:57PM +0000, 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 no
real effect on this

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. This is
accomplished using the system calls mlock(2) and mlockall(2).

Nice idea, except mlock() and mlockall() are only permissable when the 
effective userid is that of the superuser. (We touched on this a while back 
when discussing GnuPG; IIRC, in general Unix systems don't allow regular 
user processes to lock memory pages, while Windows' win32 API does allow 
such behavior.[0])

-Peter

[0] The good news is that win32 has a setting for allowing user processes
to lock pages that is distinct from the effective userid/gid; the bad news 
is that it's set per-user instead of per app; to allow users to run apps 
that insist on physical pages for memory allocation, it looks like you have 
to grant them the ability to effectively DoS the machine by grabbing all 
its physical memory. Oops.
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1099/win32/win321099.htm&nav=/msj/1099/newnav.htm

-- 
Peter Watkins - peterw () tux org - peterw () usa net - http://www.tux.org/~peterw/ 
Private personal mail: use PGP key F4F397A8; more sensitive data? Use 2D123692


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault