The rowhammer "attack" is successful only because the hardware is just plain <i>broken</i>, 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 it should be possible, since apparently previous generations of RAM don't have this problem at all. In the early 90s Intel recalled and replaced, free of charge, CPUs which didn't divide correctly. Perhaps the memory manufacturers today should do the same for rowhammer-affected modules and chips.<p>Memory errors are particularly disturbing because they are often highly dependent on data and access patterns, and can be <i>extremely</i> difficult to pinpoint without special testing tools. I've personally experienced a situation where a system which otherwise appears to work perfectly well would <i>always</i> corrupt one specific bit of a file when extracting one particular archive.<p>As a testing tool, MemTest86+ has always worked well for me, and the newer versions can detect rowhammer, although there is this interesting discussion about whether it is actually a problem (to which I say a resounding <i>YES!!!</i>) or if there's some sort of cover-up by the memory industry:<p><a href="http://www.passmark.com/forum/memtest86/5903-rowhammer-problem-not-found-by-memtest86-6-3-0" rel="nofollow">http://www.passmark.com/forum/memtest86/5903-rowhammer-probl...</a><p><a href="http://www.passmark.com/forum/memtest86/5475-memtest86-v6-2-0-released-8-sept-2015" rel="nofollow">http://www.passmark.com/forum/memtest86/5475-memtest86-v6-2-...</a><p>Run it on your hardware and if it fails, I think you should definitely complain and get it fixed.
It seems the HN title and original title are <i>both</i> 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.<p>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.<p>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 <i>would</i> be accepted as valid, assuming you can also get the target machine to download said package.<p>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.<p>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.
Here's the crux of the memory issue from one of the link in the article:<p>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.
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). <a href="https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2097593" rel="nofollow">https://kb.vmware.com/selfservice/microsites/search.do?langu...</a>
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.)<p>But that's just <i>this</i> attack - the fact that they have that much control over memory means there are FAR FAR FAR more possible attacks.<p>If you can control memory to that level then you are limited only by your imagination.<p>The only mitigation I can think of at the moment is ECC memory. And shame on Intel for only supporting that on Xeon.
It is more costly, but this is a good reason to use a dedicated chunk of memory for every Xen PV domU. No oversubscription!<p>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.
"For the attacks to work, the cloud hosting the VM must have deduplication enabled so that physical pages are shared between customers."<p>But the vendor's cloud will not disable sharing pages of physical memory because ____.<p>This is a great counterpoint to the salesman trying to sell you on "cloud" anything.<p>Why is it less expensive to use the "cloud"?<p>One reason is because you do not get your own physical server, including your own RAM.<p>When the "cloud" buzz began to gain momentum years ago I raised the issue of not knowing who your "neighbors" were on these physical servers that customers are sharing with other customers in datacenters.<p>As usual, these concerns will just fade into the background... again.
For those of you worried about your aws workloads, this may help make ya feel a (slight) bit better.<p><a href="https://forums.aws.amazon.com/thread.jspa?messageID=739485&tstart=0" rel="nofollow">https://forums.aws.amazon.com/thread.jspa?messageID=739485&t...</a>
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...
<i>For the attacks to work, the cloud hosting the VM must have deduplication enabled so that physical pages are shared between customers.</i><p>This "Flip Feng Shui" wouldn't work in SmartOS simply because the hypervisor does not implement memory deduplication.<p>Good luck with VMware though.
It seems like a dedicated server would solve this issue in some sense. If your not on a shared VM, then an attacker could not affect the memory.<p>For those that cannot be on a dedicated server, what changes could be made to the shared VM memory setup to reduce this attack surface?
some thoughts:<p><pre><code> For the attacks to work, the cloud hosting the VMs must have deduplication enabled so that physical pages are shared between customers.
</code></pre>
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<p>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.