did you really expunge that key?

Simon Josefsson jas at extundo.com
Sat Nov 9 00:01:25 EST 2002


pgut001 at cs.auckland.ac.nz (Peter Gutmann) writes:

>>Which operating systems "leak" memory between processes in this way?
>
> Win32 via ReadProcessMemory.  

The documentation for the function says it will check read access
permissions.  Isn't this permission check done properly?  I.e.,
disallow memory reads across processes owned by different users.  If
so, this should be reported and fixed.  The remaining situation seems
to be if ReadProcessMemory() on the running process "leak" data
initialized by dead processed owned by other users, any pointers to
information on this case would be appreciated.

> Most Linux systems which set up the user as root when they install
> the OS.  The combined total would be what, 97%? 98%? 99%? of the
> market?

If you can run a program as root, aren't there easier way to discover
passwords than allocating memory initialized by other processes?
E.g., attaching a debugger to /bin/login.

>>Which operating systems write core dumps that can be read by non-privileged
>>users?
>
> Watson under Win32, any Unix system with poor file permissions (which means a
> great many of them).  Again, that's most of the market.
>
> This *is* a serious issue, which is why any security software worth its salt
> takes care to zeroise memory after use.

My point is that the software in general cannot solve this without
help from the operating system.  In particular, software cannot
protect itself from operating systems bugs that reveal secret data
handled by the software.  If you run security software on a insecure
host, you won't achieve security no matter how good the security
software is.  A pair of functions secure_memory_allocate() and
secure_memory_zeroize() that handle "volatile char*" data, together
with a compiler that respects the volatile property, seems like a
useful interface.  No doubt, this already exists.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



More information about the cryptography mailing list