Live data from Hacker News

New cloud attack takes full control of virtual machines with little effort

arstechnica.com

1–10 of 105 posts

Re: New cloud attack takes full control of virtual machines with little effort

#2
It is more costly, but this is a good reason to use a dedicated chunk of memory for every Xen PV domU. No oversubscription!

Allowing multiple domU VMs on the same dom0 (or the equivalent in other hypervisor platforms) to re-use memory and balloon/contract memory on the fly is what enables this.

Re: New cloud attack takes full control of virtual machines with little effort

#3
This attack wouldn't work with [current versions] of ESXi since VMs now share pages only if the salt value and contents of the pages are identical (each VM uses a unique salt by default). https://kb.vmware.com/selfservice/microsites/search.do?langu...

Re: New cloud attack takes full control of virtual machines with little effort

#4
Here's the crux of the memory issue from one of the link in the article:

DDR memory is laid out in an array of rows and columns, which are assigned in large blocks to various applications and operating system resources. To protect the integrity and security of the entire system, each large chunk of memory is contained in a "sandbox" that can be accessed only by a given app or OS process. Bit flipping works when a hacker-developed app or process accesses two carefully selected rows of memory hundreds of thousands of times in a tiny fraction of a second. By hammering the two "aggressor" memory regions, the exploit can reverse one or more bits in a third "victim" location. In other words, selected zeros in the victim region will turn into ones or vice versa.

Re: New cloud attack takes full control of virtual machines with little effort

#9
It seems the HN title and original title are both pretty wrong, at least according to the article content. The attack vector is really the ability to, if you have a known public key and a server using it, perform a pre-calculated bit flip such that the new public key is much easier to factor, and thus obtain a corresponding private key.

So you're not obtaining original private keys, you're altering original public keys so that you can more quickly factor a private key that will be accepted.

If this is an SSH public key, then you can obtain SSH access. If it's a PGP key trusted by the package manager, then you can craft signatures on packages that would be accepted as valid, assuming you can also get the target machine to download said package.

I think SSH is probably the most interesting attack vector assuming you can get network access to the host once you've jumped through the myriad hoops to perform this attack.

It's a serious issue that should be addressed (probably via forced from-disk reads or at minimum integrity checks), but I think the authors are perhaps a little too eager on the practical implications of corrupting in-memory public keys.

Post reply on HN