

Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack [pdf] - pedro84
http://eprint.iacr.org/2013/448.pdf

======
IbJacked
So, according to this paper, "GnuPG in its current form is not safe for a
multi-user system or for any system that may run untrusted code."

The attack is against the RSA implementation specifically. Is there a gpg
asymmetric encryption that _would_ be considered safe? If not, is there a
reasonable gpg alternative?

~~~
alcari
With their same logic, your software based CSPRNG isn't safe, and your browser
isn't safe, and your full disk encryption isn't safe and all it requires is
the trivial feat of being able to run arbitrary code as arbitrary users on
your system without your knowledge.

~~~
bigiain
From the article:

"Furthermore, as virtual machine hypervisors transparently share memory pages
between VMs [5,19], the attack is applicable across the isolation layer
between VMs"

It's saying your VMs aren't safe - your
Amazon/Linode/Rackspace/DigitalOcean/NineFold/Hertzner cloud instances _do_
have arbitrary users running arbitrary code on them – and the hypervisor can't
protect you against what they do (in terms of manipulating the shared cache).

~~~
bcoates
The only reason for these operators to do memory sharing would be if it
allowed them to oversubscribe RAM--is there any reason to believe any of them
are doing that? It seems like it would lead to extremely noticeable and severe
performance or stability issues in edge cases unless the provider required you
to run a specific image on your instance.

------
daemon13
So, practical question

I am on Ubuntu LTS 12.04 with GnuPG 1.4.11 (Linux version 3.2.0-32-virtual
(buildd@batsu) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)).

Q1. Do I need to fix this potential attack?

Q2. Assuming this fix is not backported [now] - if I compile fresh gpg and
swap the binary with the old gpg - will this fix it?

~~~
mrich
Q1: Yes, it is fixed in 1.4.14 only.

Q2: Cleanest would be to uninstall GnuPG and install latest from source. Make
sure to backup relevant directories containing GnuPG related data (probably in
your home - sorry I'm not familiar with Ubuntu)

~~~
e12e
BIG WARNING - THIS IS NOT THE BEST WAY TO INSTALL GNUPG! IT DOES NOT VERIFY
ANY (REAL) SIGNATURES!!

FYI - Debian unstable (aka sid) has a pacakge, and there is a backport to
Ubuntu Saucy. I'm not sure what the best/easiest way to _automatically_ pull
down sources for a newer release than the release you're running in Ubuntu
(there might be some apt-add magick for source mirrors?) -- but since it is up
at launchpad[1], you can:

a) try the binaries b) build the debs yourself (aka manually "backport"):

    
    
        mkdir tmp/gnupg -p
        cd tmp/gnupg
        sudo apt-get build-dep gnupg
        sudo aptitude install dpkg-dev #This might get pulled
                                       #in by the line above
        wget https://launchpad.net/ubuntu/saucy/+source/gnupg/1.4.14-1ubuntu1/+files/gnupg_1.4.14.orig.tar.gz \
             https://launchpad.net/ubuntu/saucy/+source/gnupg/1.4.14-1ubuntu1/+files/gnupg_1.4.14-1ubuntu1.debian.tar.gz \
             https://launchpad.net/ubuntu/saucy/+source/gnupg/1.4.14-1ubuntu1/+files/gnupg_1.4.14-1ubuntu1.dsc
    
        tar xzf gnupg_1.4.14.orig.tar.gz
        cd gnupg-1.4.14
        tar xzf gnupg_1.4.14-1ubuntu1.debian.tar.gz
        cd debian
        dpkg-buildpackage
        cd ..
        sudo dpkg -i gpgv_1.4.14-1ubuntu1_amd64.deb \
                     gnupg_1.4.14-1ubuntu1_amd64.deb \
                     gnupg-curl_1.4.14-1ubuntu1_amd64.deb
      

Note: This might not be a good idea with a package that is as imprtant as
gnupg (among other things apt package lists are signed with gnupg!). And as
you can also see above, the packages are not signed (explicitly, even if they
do come in via https...).

At least this built fine under wheezy -- but I haven't tried installing them
(I'm not that worried that someone will snoop my workstation cache..).

So not really meant for advice on how to get an upstream _gnupg_ \-- but
useful with a few other well-behaved programs. So big warning, practice safe
hex and all that!

------
nn3
The key part is the first line in the abstract

"Flush+Reload is a cache side-channel attack that monitors access to data in
shared pages"

The OS does not allow arbitary programs to share pages with gpg. If you share
pages with gpg you can already read the key directly, no need for any side
channels.

As far as I can tell the paper is completely pointless, a variant of this
fallacy
[http://blogs.msdn.com/b/oldnewthing/archive/2009/01/21/93533...](http://blogs.msdn.com/b/oldnewthing/archive/2009/01/21/9353310.aspx)

~~~
tlb
It does this with code pages, to trace the control flow. All modern OSes let
you map code read-only (either static or shared libraries) into multiple
processes while sharing the physical memory.

~~~
nn3
The paper describes flushing the data pages. I don't see anything about the
code pages in their algorithm.

~~~
tlb
It's confusing, but the "data" is instructions. It's explained in the first 4
paragraphs of section 5.

------
sspiff
Can someone knowledgeable about security tell me if there is anything about
their claim (98% in one round) that is exaggerated or "best edge case only"?

I wonder how these attacks would fare against NaCl[1] or Sodium[2], who were
designed to be secure against side-channel attacks.

[1]: [http://nacl.cr.yp.to](http://nacl.cr.yp.to)

[2]: [http://labs.umbrella.com/2013/03/06/announcing-sodium-a-
new-...](http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-
cryptographic-library)

~~~
mrich
They have quite some preconditions that need to be in place:

\- You must know the code locations of the instructions that you target
exactly. I.e. you will need to get down to the exact cache line of the
operation in the compiled binary of the attacked program. They solve this by
using a binary with debug symbols, in practice this will be harder as the
binary will likely be stripped from debug symbols.

\- You can bet that there will be differences in the attack depending on the
model of processor, let alone the manufacturer that will make it very hard to
generalize this attack, increasing its cost.

I think there are cheaper attacks for criminals/government agencies. Also, as
mentioned below it is already mitigated by a GPG fix. But I found the paper
quite interesting as I never considered such an attack before.

------
contingencies
Gentoo bug @
[https://bugs.gentoo.org/show_bug.cgi?id=478184](https://bugs.gentoo.org/show_bug.cgi?id=478184)

