Flip Feng Shui: Perturbation attacks made it to VMs

Perturbation

I’ve been reading up on the Flip Feng Shui: Hammering a Needle in the Software Stack paper, and I’m enjoying that the common smart card attack considerations are coming to more mainstream software considerations.

From the paper:

We describe Flip Feng Shui (FFS), a new exploitation vector that allows an attacker to induce bit flips over arbitrary physical memory in a fully controlled way. FFS relies on two underlying primitives: (i) the ability to induce bit flips in controlled (but not predetermined) physical memory pages; (ii) the ability to control the physical memory layout to reverse-map a target physical page into a virtual memory address un- der attacker control.

This first item we call “perturbation attacks” in smartcard domain. We do those attacks all the time, by giving our poor smartcards power spikes it really shouldn’t be exposed to, prodding it with probing needles too small for the human eye, shooting it with freaking lasers, … you know: standard Monday morning stuff in the office*.

Because we’ve been doing this for ±20 years now in this domain, it takes a while for me to understand a statement like the following is not a joke:

existing cryptographic software is wholly unequipped to counter it, given that “bit flipping is not part of their threat model”.

Because in my world, bit flips are a given, considering that there is an attacker playing with the smartcard. Monday morning remember?

So how does this attack work?

The attack (mis)uses memory de-duplication, i.e. a feature in the host hypervisor that sees that the page of memory of one VM is identical to another one VM’s. When this is enabled, the host hypervisor then maps both these pages to the same page (to reduce actual used physical memory by 40-70%!). If the attacker was the one who created that page originally, he now owns the actual physical page. As long as the host software thinks this page’s content has not changed, the victim VM will read the attacker’s physical page.

So the attacker then does a Rowhammer attack to cause a bit to flip in the part of “his” page. As Rowhammer is a physical side-effect that ‘should not happen’, the host hypervisor does not see the page as changed, even though it is. So now the attacker has just caused a bit flip in his own and, more importantly, this victim’s memory.

Flipping a bit in say a RSA public key allows the attacker to factor that modified key, and generate the appropriate secret key to match. If the attacker does this with the RSA key say used to authenticate root access for SSH, or the signature key for package updates of Linux, he now has full control over that machine.

Neat! (In smartcard world we usually attack the secret key, because of how the protocols are used.)

Theory or practice?

Now, to successfully pull off this attack, several things have to be possible for the attacker:

  • predicting the memory content (this excludes attacks on confidential information such as secret keys),
  • memory de-duplication must be active (so disabling that, or setting it to “only zero pages”, seems prudent),
  • the attacker must be running his VM on the same physical machine as the victim’s VM (I don’t know if this is a realistic scenario. More on it below)
  • the memory must be sensitive to something like Rowhammer (so ECC memory is yet again a good idea, it will reduce the chances of this significantly)

Realistic to be the neighbour of your victim VM?

This attack depends on being able to run the attack VM on the same hardware as the victim VM. I have no well-founded grounds to guess if this is a realistic assumption.

I can think of the following situations where that is possible:

  • The pool of actual hardware is pretty small compared to the amount of VMs, because the hardware is very beefy or the VMs are small.
  • The amount of instances of the victim VMs is pretty big, because it is a standard VM replicated many, many times. I think about situations like massively parallel computing or streaming (Netflix?).
  • Or the targeted page is very common, and here I’m thinking of the signature files for updates for example, or company wide backup root accounts.

My conclusion: stay calm and …

Considering all the complexity of this attack, I don’t see it worm all over the Internet soon. It is however a cool warning that attack can and do cross over from these various fields.

I wonder when they’ll realise they can also apply this attack to modify the running code of say the password check routine