13

Row Hammer is an exploit which relies on RAM defects to get unrestricted access to the RAM content, allowing to read/write otherwise protected memory and to get higher privileges on the system.

To work, this exploit will access a legitimately accessible memory row in a loop at a very high rate and with no cache, and the frequency of this operation will induce a change in the value of the adjacent, restricted row.

Wikipedia describes the exploit as follow:

By combining the disturbance errors with memory spraying, this exploit is capable of altering page table entries (PTEs) used by the virtual memory system for mapping virtual addresses to physical addresses, which results in the exploit gaining unrestricted memory access.

As per my understanding, while this exploit may be able to provide the attacker a Super User privilege on a guest system (I do not talk about "root" since this attack is not OS dependent), I'm wondering if it can really allow him to escape the virtualized guest and reach either other guests or the host system itself.

  • While this attack is described as providing "unrestricted access to all physical memory installed in a computer", this memory must still be addressable by the malicious process. As per my understanding a guest virtualized "physical" memory is mapped onto a region of the actual physical memory and several measures exists, both at the hardware (CPU with hardware-assited virutalization instruction sets) and the software (the virtualization software) layers, to ensure it will not be able to address memory outside of this area.
  • In order to access normally restricted memory areas, the process has to modify the PTEs. Within the guest, only the PTEs of the guest system is accessible, not the PTEs of the host one.
  • There is a chicken-and-egg problem: in order to circumvent the memory access enforced by the virtualization software, the process must alter its memory. However, since the virtualization software is running on the host system, the malicious process must first be able to address host system memory in order to do this.
  • Wikipedia's definition mentions modifying the PTEs (Page Table Entries). Modern CPUs provide Second Level Address Tanslation (SLAT, aka nested paging to isolate guest's page tables at the hardware level). Would my assumptions above be bypassable, would this improve the resistance of virtualized systems against Row Hammer?
3

It depends on your adversary, though I will say no.

At the moment, there are no known vulnerabilities for this attack vector. Thus, if your adversaries are script kiddies, then you are safe.

It will be a box of chocolates (not knowing what you might get), thus a useless attack:

  • A vulnerability likely might allow someone to read or modify a different row, but not knowing what information is where makes it nearly useless, thus eliminating most any adversary.
  • The HV layer can re-map or even swap out memory at any given moment
  • The HV might have a dozen or a hundred different VMs, there's no way to target one.
  • The HV might do something like VMotion and move it to a different hardware host
  • Even doing Row Hammer on the same VM to get elevated privileges is subject to the above, making it unpredictable.

When your threat / adversary has unlimited funding and is targeting you specifically, all bets are off, though likely, they would seek an easier path into the environment, including physical attacks.

Given the number of 0-day vulnerabilities, even those on Hypervisors themselves, Row hammer seems kinda pointless.

  • you can get through pains of verification of host/guest OS and prove that there is no way to break from guest to host -- at least in theory. BUT row hammer will make your efforts pointless because it uses non-deterministic mechanism based on properties of hardware you don't have neither access nor information about. I.e. there is no guarantee that your cloud app containing important data would not be compromised -- no matter how much you try. Would anyone agree with that? – lowtech Feb 17 '17 at 22:19
  • @lowtech: Unless you use ECC RAM (which should be the case for the majority of professional cloud hosting solutions I suppose / hope) or RAM designed to specifically circumvent this attack (as mentioned in your linked article, but I think this is merely theoretical yet). Being an hardware issue, the real solutions can only be at the hardware level (I'm quite skeptical about the software integrity checks proposed in your article). – WhiteWinterWolf Feb 18 '17 at 20:13
  • @lowtech: MikeP's point here is that while you can still technically use the attack, it is not exploitable since you cannot target anything, but your article shows that depending on the hypervisor's settings there may be exception(s). – WhiteWinterWolf Feb 18 '17 at 20:15
  • @WhiteWinterWolf the problem is that there is no security guarantee possible for cloud applications and data because of rowhammer and fengshuiflip. i am interested in that as argument against cloud-based infrastructure. fengshuiflip described here: arstechnica.com/security/2016/08/… – lowtech Feb 19 '17 at 0:31
  • 1
    @lowtech: Regarding rowhammer and fengshuiflip, no matter the hypervisor settings you are still safe as long as the cloud service provider use ECC RAM on all the hosting machines as part of their general security and reliability process, however I don't know if anyone has a formal engagement about this and, even if they do, its mostly a matter of trust if you believe them or not. On a more general perspective, this issue mainly reminds us that the idea that "Shared virtual machines are as safe as dedicated hosts" is a purely marketing concept and not a technical fact. – WhiteWinterWolf Feb 19 '17 at 9:53
1

I think this needs to be broken down into smaller questions that can be reasonably answered.

Can the a VM repeatedly access the same memory address quickly enough to trigger the row hammer effect?

I see no reason why that would be impossible. It is certainly possible that something about the virtualized environment could end up interfering with that process. A Virtualized environment could theoretically monitor for that type of access pattern and try to block it but I suspect the overhead would be pretty bad and would negatively impact performance. I don't know of any off hand that actually implement this. It is also certainly possible that it could interfere with the process accidentally. As MikeP mentioned it could just happen to remap the memory in the middle of the attack or trigger a migration to another server in the middle of the attack or even simply preempt the VM to allow another VM to run. I'd assume the VM would try to avoid remapping memory that is being heavily used as that would likely have a negative performance impact but a VM migration could be triggered if the virtual environment sees the row hammer attack as a memory pressure and is trying to "fix" that.

The next question is if you can get a bit to flip can you use it to actually accomplish something?

IMO this gets far trickier. The virtualized environment adds at least one additional layer of address translation that makes identifying a row hammer target and that target could change at any time. It might also hide information about the underlying physical layout necessary to properly identify a target. I think these challenges on top of potential challenges even triggering the bit flip do make this impractical and probably make crafting a reliable exploit impossible. You are far more likely to essentially create a DoS attack by crashing a VM or the entire virtual environment than a reliable privilege escalation.

0

The theoretical success of a Row Hammer Attack in your scenario is given. But the practical possibilities might be limited or the complexity of the attack chain very high. This is not a limitation by Row Hammer per se, it is a dependency of the real-world scenario. An attacker in one Guest would have to affect the Host to gain elevated privileges or to affect another Guest directly. This might be possible under some circumstances but would require a very good preparation, a lot of time and even some luck.

  • Thanks for your answer, but it leaves me wanting more ;). You say "This might be possible under some circumstances but would require a very good preparation, a lot of time and even some luck.", can you be a bit more explicit on the circumstances which would help or prevent such attacks and the kind of preparation it would require so I can get a better idea of the threat reality? For instance, theorically the whole asymmetric cryptographic world is weak since theorically someone may come-up at anytime with a solution to factorize large numbers, however practically this risk is negligible. – WhiteWinterWolf Jun 26 '16 at 8:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.