did you really expunge that key?

[Peter Gutmann]

Simon Josefsson <jas at extundo.com> writes:

>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.

Almost all Win32 systems (except for a few Citrix-style systems) are single-
user, so the check is irrelevant.  Even if it's running in a different user
context, for Win9x systems that's meaningless, and for NT systems it's pretty
safe to assume the user is Admin so you can get to anything anyway.

>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.

The problem is someone running a program 3 days later and finding keys in
memory, not active attacks.

>My point is that the software in general cannot solve this without help from
>the operating system.

It can do a pretty good job of it.  Zeroising a key after use on a system
which isn't currently thrashing gives you a pretty good chance of getting rid
of it.

(Yes, you can hypothesise all sorts of weird places where data could end up if
 you're not careful, but to date multiple demonstrated attacks have pulled
 plaintext keys from memory where they were left by programs, and not from
 keyboard device driver buffers or whatever).

>If you run security software on a insecure host, you won't achieve security
>no matter how good the security software is.

Right, so we'll just given up even trying then, and wait for the day when
secure systems are readily available.

>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.

Nope.  NT (not Win9x) has VirtualLock(), but there are special issues
surrounding this which are too complex to go into here, and Unix doesn't have
anything (mlock() won't cut it).

BTW I misattributed the previous message in my reply (I'm posting from another
system and had to manually edit the reply), apologies for any confusion this
caused.

Peter.

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