Bug: sensitive data written to insecure memory

[Andrew Archibald]

On Tue, Apr 03, 2001 at 11:50:58PM +0200, Florian Weimer wrote:
> Andrew Archibald <aarchiba@yahoo.com> writes:
> 
> > In a number of the cryptographic algorithms (for example, cast5.c and
> > rijndael.c) sensitive data are written to temporary variables, which are
> > stored on the stack.
> 
> I've independently discovered similar problems in the MPI
> implementation and/or the asymmetric ciphers (it's not clear which one
> is the culprit).
> 
> I think a rough audit of all related code is required, and if the
> problem appears to be fixable with a limited amount of work (which,
> when done properly, would have to involve changing some of the MPI
> assembler primitives), it should be fixed.

Yack.  Not that it's a good idea, but if we were running as root the whole
time, we could mlock() the relevant hunks of stack.  How expensive would
preemptively mlock()ing the whole stack be?  GnuPG is not a long-running
process under normal conditions.  If all else fails, there's mlockall().
How hard is it to play games with the C stack?  (I mean, call a C function
with stack in a piece of secure memory).

How hard would it be to write a secure_alloca?  One could model it on the
alloca implementation for compilers with no alloca that circulates as part
of a lot of old GNU software.  That's not too slow, and tweaking the
various routines to do it wouldn't be hard (it took me ten minutes to hack
rijndael-alg-fst.[ch] to accept scratch space passed in).

> Otherwise, the whole concept of secure memory should be dumped, and
> the use of operating systems with encrypted swap space should be
> recommended in the documentation.
> 
> (Everything IMHO, as always.)

If we can't be perfect, we can be better than nothing.   How much does the
secmem stuff actually cost?  It is probably worth leaving in, even if most
people use GPG without secure memory.  Unfortunately the most common
platform does not appear to allow encrypted swap[1].  And very few people
will switch platforms.  The net result of this would be to make GnuPG less
secure for almost everyone.

As a basic first step, we could just ensure that the stack is wiped of
sensitive data after each routine that stores sensitive data there.  Then
the window of vulnerability is much narrower.

FWIW, it's not very hard to port things to use scratch memory.

Andrew Archibald

[1]The Linux International Kernel Patch contains lengthy warnings about a
race condition when swapping to an ecrypted block device.  Whether it's
been fixed I don't know, although I have haerd a report of someone doing it
successfully.  Regardless, it's not as good as OpenBSD's encrypting swap;
you have one key for each reboot, and you have to write all the scripts
yourself.