Shared memory attack on exponentiation crypto
This paper just came out:
http://eprint.iacr.org/2013/448.pdf
It's quite exciting, really. In summary, by running another process
which maps the gnupg executable and plays tricks to detect L3 cache
fills, they can recover the private key used in a gnupg signature
operation.
This is a threat in any multi-user system. It's also a threat in a VM
scenario if you have a page-sharing system.
I think in Debian our responsibility is at least to try to fix the
multi-user problem. The simplest way seems to be to avoid having
crypto processes share their pages with other processes.
I wrote a simple function which unshares all of the relevant file
mappings:
http://www.chiark.greenend.org.uk/ucgi/~ian/git/map-unshare.git/
It seems to work in the simple test program, for me, on i386. It's
not threadsafe (and making it threadsafe would be quite tricky). It's
also Linux-only, but I guess FreeBSD must have ways to do this.
Is trying to plumb this into various crypto executables a reasonable
approach ? Doing this to ssh, sshd, gpg, etc., would seem quite
straightforward and probably reasonable from a performance point of
view. (Single-user embedded systems should have a way to turn it
off.) Web browsers might be a problem because you probably don't want
to unshare the whole of the executable and libraries.
Another possibility would be to try to provide a set of
LD_PRELOAD-based hooks, thus providing a toolkit for retrofitting the
page-unsharing without having to patch and rebuild everything of
interest.
Ian.
Reply to: