Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

51–60 of 105 posts

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

#51

Post by runeks »

caf wrote: post #5

I wonder if it would be worth checksumming public keys and re-checking the checksum each time it's used?

That's security by obscurity (which may work to delay the attacker). If an attacker can modify your public keys he can modify your checksums as well.

Seems to me that a public key should be identified by a cryptographic hash of it, rather than the public keys itself. Then the attacker would need to replace the entire hash, rather than just a few bits, because the hash changes completely just by flipping a single bit in the input.

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

#52

Post by willvarfar »

nickpsecurity wrote: post #15
userbinator wrote: post #14

The rowhammer "attack" is successful only because the hardware is just plain broken , and I consider it in the same category as things like a CPU which will calculate 1+1=3 if the computation of 1+1 is done enough times --- nothing software should even try to fix, because the problem is at a lower level. The solution is to demand that the hardware manufacturers make memory which actually works like memory should; and…

There's CPU's that do memory, integrity checking to contain attacks. They're designed for stoping software and peripheral attacks mainly but consider RAM untrusted. They could probably be modified to deal with the new attacks.

Encrypted RAM is offered by the newest Intel server-grade CPUs (SGX, Skylake) and the next AMD server-grade CPUs (SME, Zen).

One of the main use-cases for these technologies is trusted computing in a cloud environment - the customer can assert that the hardware is securing the program state from the eyes of the computer owner!.

However, the cloud is actually made from cheap commodity boxes without server-grade anything! ;)

Encrypting RAM pages would prevent the hypervisor from deduping pages between virtual machines, and this would be very negative for cloud providers who want to up the occupancy on each box as much as possible...

In a few years, or perhaps longer, perhaps proper DDR4 and other immune memory will be mainstream in clouds. But until then, it seems we'll have a cloud fitted out with increasingly aging cheap machines with no rowhammer immunity.

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

#53

Post by jfoutz »

runeks wrote: post #46
xorgar831 wrote: post #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 hac…

So it doesn't allow reading any data? I'm most nervous about leaking private keys.

in and of itself, no. but it could alter a permission bit, for example, and then reading would be allowed.

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

#54

Post by caf »

runeks wrote: post #51
caf wrote: post #5

I wonder if it would be worth checksumming public keys and re-checking the checksum each time it's used?

That's security by obscurity (which may work to delay the attacker). If an attacker can modify your public keys he can modify your checksums as well. Seems to me that a public key should be identified by a cryptographic hash of it, rather than the public keys itself. Then the attacker would need to replace the entire hash, rather than just a few bits, because the hash changes completely just by flipping a single bit…

The attacker isn't making targeted modifications to your public keys, though: they're randomly glitching it, and using the page sharing implemented by the hypervisor to read out and factor the glitched version.

Even with say a 64 bit checksum then there's only a 1 in 2^64 chance of the randomly modified key/checksum pair matching. But you could use a cryptographic hash as your checksum if you wanted.

I only suggest this not because I think it would be a complete defence against all Rowhammer attacks - it wouldn't - but because the general fragility of the RSA construction means that doing it with any potentially corrupted input gives me the willies. There are other sources of bitflips other than Rowhammer and it just strikes me as a generally good idea not to leak the results of RSA operations performed on potentially bitflipped inputs.

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

#55

Post by lifeisstillgood »

some thoughts:

  For the attacks to work, the cloud hosting the VMs must have deduplication enabled so that physical pages are shared between customers.
This seemingly is an attack where two VMs on the same host can read each other's memory, if a deduplication flag is set on the VM controller. This seems to offer cloud holsters some easy (paid for) upgrades to be honest

its not (afaik) heartbleed time. It's bad but the effort required is high and afaik the attacker will replace your key with their key - making it clear you are compromised.

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

#56

Post by walrus01 »

runeks wrote: post #49
walrus01 wrote: post #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.

Can you point me to some services that provide, specifically, Xen PV VMs with non-oversubscribed memory? I'm considering deploying a custom unikernel for protecting the private key data for my app[1], until I have enough money for a Hardware Security Module. [1] http://security.stackexchange.com/questions/135457/penetrati...

Sorry, I can't, we use Debian stable + xen on our own bare metal hardware machines with from 256gb to 1tb of RAM. Never tried to buy a rental VM using the same dom0+PV setup. All of my off site VMs are for testing, some cheap $4/mo type openVZ that are basically glorified jails.

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

#57

Post by makomk »

willvarfar wrote: post #52
nickpsecurity wrote: post #15

Earlier quoted context omitted.

There's CPU's that do memory, integrity checking to contain attacks. They're designed for stoping software and peripheral attacks mainly but consider RAM untrusted. They could probably be modified to deal with the new attacks.

Encrypted RAM is offered by the newest Intel server-grade CPUs (SGX, Skylake) and the next AMD server-grade CPUs (SME, Zen). One of the main use-cases for these technologies is trusted computing in a cloud environment - the customer can assert that the hardware is securing the program state from the eyes of the computer owner!. However, the cloud is actually made from cheap commodity boxes without server-grade anythi…

Don't think I've seen any non-server-grade processors in even the cheapest bargain-basement VPS hosts. (Low-end dedicated is different.) Cramming as many VMs into a big server as possible seems to be too important to their cost structure for that.

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

#58

Post by ploxiln »

runeks wrote: post #42

Ouch. Before reading this article I was seriously considering deploying a signing service as a HaLVM (Haskell) Xen PV unikernel running on EC2. The service would receive its private key after startup, such that the key never touches disk. Now I'm a lot less inclined to pretend that the Xen interface actually protects me...

Xen has had page-table and interrupt vector related security vulnerabilities. But I don't think EC2 would use non-ECC RAM, so I don't think it's vulnerable to this "rowhammer" technique. (I also don't think EC2 would do cross-VM page deduplication, another necessary condition.)

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

#59

Post by Dylan16807 »

ars wrote: post #16

People are focusing too much on the exact specific attack shown here: Deduplication, modifying a public key, etc. (And proposing solutions like turning off deduplicaiton, checksum, etc.) But that's just this attack - the fact that they have that much control over memory means there are FAR FAR FAR more possible attacks. If you can control memory to that level then you are limited only by your imagination. The only mi…

If you control memory vs. if you control your memory. This does not give you general purpose access.

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

#60

Post by Dylan16807 »

jerf wrote: post #27
Afforess wrote: post #19

Earlier quoted context omitted.

I don't agree, there is software that is designed to run on faulty hardware. This is often in high radiation environments (see: outer space). I agree this is not an area that much hardening has been done in conventional security models, but in other environments, it is common to use CRC error detection, parity information or other means to ensure that even if data is partially corrupted, that the original can be rest…

Hostile environments attack your software without intelligence. (When working with them, it may seem otherwise, but that's just cynicism.) Hostile people attack intelligently. Whatever mitigation you may imagine is possible by checking CRCs or something after the fact, you must account for the possibility that the software, the OS, or the CRC has also been attacked by a hostile intelligent adversary. The fact that we…

Rowhammer is largely random. You don't get to target specific bits of physical ram. You find scarce weak bits and work to get the data located there. In this case that means you can only pick a couple bits per 4KB to attack. That won't let you fake out a CRC.
Post reply on HN