Flipping heck! Virtual machines hijacked via bit-meddling Feng Shui Security researchers at the Vrije Universiteit in Amsterdam have found a way to subvert virtual machines using a combination of hardware and software shenanigans. The end result is the ability to flip bits in another VM's memory to weaken its encryption or mess with its operation. The attack, dubbed Flip Feng Shui, works by …
In case anyone reads comments but didn't follow the article's link to the docs, it is easy to disable this feature on a system. Also, if you rebuild your own kernel, there is a config flag to remove the feature completely.
So, good to know about this attack, but nothing to panic about.
The thing is, if your environment is one where you control the physical host, you probably also control all the VMs running on it, so there's no problem.
If you are in a shared cloudy environment*, you almost certainly don't control the physical host and probably don't control all the VMs running on it.
In other words, yes, you can disable the feature in software, but if you're in a position to do that, you aren't vulnerable anyway.
*A cloudy environment is one where you can't see everything that's going on.
My feeling is that ECC memory won't help. All it will tell you is that an error has occurred. The reason being is that the ECC elements are simply extra elements of the vulnerable "modules" which will also be susceptible to having their states flipped. (ECC is a "participant observer")
The whole thing about DDR is that it is by definition "fly by wire" to achieve the speed of access that it does. Refresh it too fast and you get corruption, don't refresh it fast enough and you get corruption. By stressing the power going into the circuitry harmonic frequencies are being created which are affecting the refresh rate of the RAM, pulling it out of tolerance, and hence corrupting it. A well designed power supply will help quench this waveform lumpiness, but if the circuit board design is not up to scratch then this can cause local impedance issues which wouldn't be relevant in normal operation.
I wouldn't have thought that this kind of attack is reproducible in terms of which bits get flipped.
Is there any guarantee this same trick couldn't attack the host itself? Is VM RAM data stored in some way that makes it too different from other data in physical RAM so that it's impossible to make them match? Or is there anything else I'm missing about how this page merging feature works that would protect against this?
As far as I can see this only works on writable memory. Else how do you flip the bits rapidly?
Sharing read only code between processes is as old as the hills.
So apparently you need to take a copy of a writeable area of memory which remains unchanged long enough for deduplication to kick in. You then have two (or more) processes with write access to the same memory area?
This just doesn't sound right because if you could do this you would have read and write access to the memory anyway and wouldn't need to do fancy bit flipping.
I think you could identify a read only area of memory, and if you could identify the absolute hardware address then gain write access to physical memory very close to it you could go for rattling the cage. However, can you do this in a VM?
Nope, beyond me.
"a Rowhammer attack. This technique, revealed by Google engineers last year,"
It's been known since the early 1970s, actually, long before the goo-tards were even aware that DRAM existed ... in fact, before many of them were even born. We called the effect a more logical "induced disturbance errors", instead of the video game inspired "rowhammer", not being teh L33t 4ax0r5 that teh goo-tards are.
Oh jake please. Since the early 70s, really? When there was 32 KiB discrete element memory and frequency on the bus was measured in kHz?
"induced disturbance errors" must have been the high-falutin way of saying "there is crosstalk on the lines, somebody please get a soldering iron out". Not at all like "rowhammer" ... (does that name come from a vidya? I dunno)
This post has been deleted by its author
Just a few helpful links for you KVM guys out there:
Disable per guest:
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatbpkvmuseguest.htm
Disable globally(RHEL)
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/chap-KSM.html
If you disable it globally best to list it in the xml of every VM too since update of libvirt may re-enable the ksm and ksmtuned service.
but how on earth are you going to create a duplicate memory page without already having access to the other VM? ASLR etc would surely make this very tricky indeed to arbitrarily achieve duplication.
So... how on earth do you duplicate a page without already having access to the target machine including keys to corrupt etc.
I would also guess that this attack would show up in performance or hardware diagnostics too - it does not seem very discreet, even if it is effective.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
