41–50 of 105 posts
Will rowhammer attacks work against ECC RAM? Multibit memory errors should be detected, even if they can't be corrected.
The 'best' solution is better ram: some vendors are more vulnerable than others.
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 ke…
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...
Sharing pages seems a big price risk to pay for saving a little memory. Why not turn it off entirely?
Another benefit of the salting mechanism is that it allows the administrator to define groups of VMs that are trusted in which sharing will be performed.
disclaimer: I work at VMware and wrote the salting code.
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…
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…
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…
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...
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.
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...
Earlier quoted context omitted.
Sharing pages seems a big price risk to pay for saving a little memory. Why not turn it off entirely?
There is still significant sharing that can be achieved inside a VM, plus, a lot of the sharing come from zero pages (full of 0) which is still performed accross VMs. Another benefit of the salting mechanism is that it allows the administrator to define groups of VMs that are trusted in which sharing will be performed. disclaimer: I work at VMware and wrote the salting code.