Bug: sensitive data written to insecure memory

[Florian Weimer]

Andrew Archibald <aarchiba at yahoo.com> writes:

> Yack.  Not that it's a good idea, but if we were running as root the whole
> time,

This has a lot of nasty implications.  I wouldn't recommend to do
this.

> we could mlock() the relevant hunks of stack.

I'm not sure if GnuPG has a bounded stack size in all situations.  If
it hasn't, you've got a nice DoS (non-swappable memory is very
limited).

> How expensive would preemptively mlock()ing the whole stack be?

Impossible.  The stack can grow (usually to 8 MB or something like
that), and locking it to memory would waste 7.8 MB of physical RAM, or
something like that.  In addition, if you start enough GnuPG processes
in parallel, you'll exhaust all RAM pretty fast.

> If all else fails, there's mlockall().

Doesn't work either, I think.

> How hard is it to play games with the C stack?

It's not very portable.

> (I mean, call a C function with stack in a piece of secure memory).

Maybe some OS routines (in libc) assume a specific stack location.
Perhaps some implementations use it to access thread-local data?

> How hard would it be to write a secure_alloca?

If you know a platform reasonably well, it's a matter of an afternoon,
I suppose.  But GnuPG has to run on a lot of platforms, so even this
is not trivial.  In addition, each move in such a direction
(i.e. low-level stack fiddling) reduces the portability of the code.

> [1]The Linux International Kernel Patch contains lengthy warnings about a
> race condition when swapping to an ecrypted block device.

Encrypted swap doesn't mean swapping to an encrypted block device.
It's better to implement this at a higher level.  So you can use
per-process secret keys and discard the keys if the process ceases to
exist.