Re: [Passwordsafe-devel] SecureAllocator

[Edward E. <pas...@ed...>]

Steve Loughran wrote:
> 1. WinNT guarantees to have zeroed memory before another app asks for it.
> But the zeroing can be done in a low priority thread; it can hang around in
> unallocated state for some time. I am not sure about the win9x guarantees,
> or more importantly, how seriously to take them.

Thanks for the info. If NT makes a hard guarantee about clearing 
memory before realllocating (mind you, that's a big if), my only 
concerns with data hanging around in memory for a while is the 
possibility of it getting swapped to disk somehow.  The suspend 
feature you mention is one way.  But also, any requests to lock the 
memory with VirtualLock are surely nullified when the memory is 
released.  I don't see why the system would swap out a page that isn't 
allocated to any program, but then I'm far from an expert on Windows 
internals.  All in all, it's safer to clear the memory ourselves; a 
little overkill never hurt :).

Anything win9x "guarantees" can be taken as a mild suggestion IMO :).


> 2. It's hard to stop memory being paged out. There is an api cal for NT, ::
> VirtualLock () that can do it;  The app/user needs SE_INC_BASE_PRIORITY_NAME
> rights to be able to do this, which makes it not very useful. And its a
> no-op on Win9x.

According to the MSDN documentation, any process may lock up to its 
maximum allowed working set size into memory with no special 
privileges; SE_INC_BASE_PRIORITY_NAME is only needed to lock more than 
that, assuming you also can't increase your max working set size.

On my win2k system the max set size is something like several hundred 
KB, iirc.  Only a small portion of that should actually be used by a 
process's instruction working set, leaving plenty of memory to lock in 
a few keys or passwords.  Also, I believe memory locked with 
VirtualLock takes priority, such that explicitly locked memory can 
cause the instruction working set to be swapped out if there is not 
enough memory to satisfy both (causing horrible thrashing, but no 
security vulnerability).

Yes it's a no-op on win9x, but who runs secure multi-user code on a 9x 
box anyway?  There's no enforced memory protection, for god's sake. 
It's like keeping the deed to your house in a gunny sack on the front 
lawn.


> 3. My main fear is of laptop hibernation, at the bios level or into a
> hibernation file. The tactic here must be to go into 'erase everything' mode
> when a suspend or hibernate WM_POWER message comes in, but I also recommend
> doing the same thing when the app wakes up; a laptop's 'panic' shutdown can
> hibernate without sending a message out to anything

Excellent point.  If you have ideas or can point me to more 
information to implement this feature, I would love to do so.


> 4. the only way to really hide this stuff is in a device driver. MS have a
> service in winXP for this purpose, but I havent explored it.

My understanding agrees with this.  A device driver is the only code 
that can obtain physical memory which the system will not touch. 
However writing one is a lot of work, and it would have to reimplement 
access control to ensure each user can only access their own 
passwords/keys.  An interesting possibility, but I'm not convinced 
there's enough of a threat to make it worthwhile right now.

Thanks for all the hard info, Steve!  Let's keep this discussion rolling!

Ed