[p2p-hackers] amicima MFP and crypto upgrades

[Matthew Kaufman]

Coderman:
> i forgot to mention this previously but it is always a good 
> idea to lock memory pages where key material and cipher state 
> resides. 

Not "always". The right answer is "sometimes".

If you wish to do so, on some systems you can use memory region locking to
prevent the cryptographic material from being paged out to permanent storage
media, in theory (see below). This makes it harder to take a machine, after
the fact, and attempt to analyze its permanent media (hard disk) for any
state that might have been left behind.

However, that's just one of several possible attacks you might want to guard
against, or other requirements you might have.

> the 'mlock' function can do this on unix systems 
> (not sure what the equivalent is for win32 api).
> this does require root privilege which can make application 
> coding a little more complicated.  (i.e. handling setuid and 
> dropping privs, etc).

Here, for example, is where some of those other requirements and limitations
come in. mlock() is not only not available on Win32 (though there are calls
used by drivers, and some directX calls that can do locking that might be
applicable, though I couldn't in a quick check verify that non-paging is
guaranteed), but has different requirements and functionality on different
systems that DO support the call...

Some Linux systems and MacOS X, for instance, allow a limited amount of
mlock() by the user, but on FreeBSD, the call is unavailable except to the
superuser. In some implementations, the calls nest (MacOS X), in others
(Solaris) an inadvertant call to munlock() (or munmap(), even, which you
might be using for other reasons) by other code can unlock pages that the
cryptographic parts of your program think are still locked. And finally, and
most important, *all* that POSIX guarantees from mlock() is that the page
*is* in memory for you, *not* that it *isn't* also copied to swap. Whether
or not that's the case is implementation-dependent.

And, having an application run as setuid root, even if briefly, also
increases the risk that it would be used as a vector to run other code as
root, and clearly once an attacker can run code as root, they'd have access
to all of physical memory, not just what's stored on the swap device. That's
also true if the attacker uses some other method to get root access, or is
running on a machine where the equivalent access to physical memory is
easier to get (typical Win32 machines, for instance).

In summary, "it depends". In our case, since the MFP default cryptographic
plugin also uses the services of OpenSSL libraries for its crypto
operations, changes to ensure that state both in our plugin and the external
libraries (DLLs on Win32, shared system libraries on MacOS X and other
platforms where OpenSSL is standard, or static OpenSSL libraries elsewhere)
are all non-pagable (and more important, that "non-pagable" *also* means
"never copied to disk") is not a trivial change, especially to ensure that
that's the case on every platform we support. But as we've said before, for
applications where this is an attack you wished to guard against
specifically, there's nothing stopping you from modifying our plugin or
writing your own that implements exactly what you want.

Matthew Kaufman
matthew at matthew.at
http://www.amicima.com