Browsers, VMs and Targeted Hardware Bit-Flips
Hi all, There have been a series of recent attacks that take advantage of "rowhammer" (a RAM hardware bit-flipping vulnerability) to flip bits in security-critical data structures. VMs sharing the same physical RAM are vulnerable, and browsers and mobile apps are remote vectors with proof-of-concept implementations. Rowhammer summary: https://en.wikipedia.org/wiki/Row_hammer An attack that flips targeted bits in another virtual machine on the same physical RAM, targeting OpenSSH public keys, GPG public keys, and Debian package sources: https://www.vusec.net/projects/flip-feng-shui/ A similar proof-of-concept Android app: https://www.vusec.net/projects/drammer/ A JavaScript-based in-browser remote proof-of-concept: https://arxiv.org/pdf/1507.06955v1.pdf It seems like a short step from these existing attacks to targeting Tor Browser users remotely. I wonder whether it might be possible to target relays (or clients) using OR cells or directory documents with specific content, but this seems much less likely. I have been thinking about how we could make Tor (and browsers, and other processes, and OSs) less vulnerable to these kinds of attacks. In general, some of the process-level defences against one or more of the above attacks are: * sign or checksum all security-critical data structures, * implement and check cross-certification, * don't rely on cached checks (or checks performed at load time) continuing to be accurate, * minimise time between checking validity and using the data, (this includes signatures, checksums, data structure consistency) * make the content of memory pages (including loaded files) less predictable, * make sure the hamming distance between trusted, valid inputs and untrusted, valid inputs is large, in particular: * register domains that are one bit-flip away from trusted domains, (or, alternately, mandate SSL, and pin certificates, and fix broken CA roots) Some of the OS-level defences are: * turn off memory deduplication, * write and verify checksums on each page, Some of the firmware/hardware defences are: * increase the RAM refresh rate, * improve RAM design, * use ECC RAM. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 2016-11-18 00:03, teor wrote:
Hi all,
There have been a series of recent attacks that take advantage of "rowhammer" (a RAM hardware bit-flipping vulnerability) to flip bits in security-critical data structures.
VMs sharing the same physical RAM are vulnerable, and browsers and mobile apps are remote vectors with proof-of-concept implementations.
Rowhammer summary: https://en.wikipedia.org/wiki/Row_hammer
An attack that flips targeted bits in another virtual machine on the same physical RAM, targeting OpenSSH public keys, GPG public keys, and Debian package sources: https://www.vusec.net/projects/flip-feng-shui/
A similar proof-of-concept Android app: https://www.vusec.net/projects/drammer/
A JavaScript-based in-browser remote proof-of-concept: https://arxiv.org/pdf/1507.06955v1.pdf
It seems like a short step from these existing attacks to targeting Tor Browser users remotely. I wonder whether it might be possible to target relays (or clients) using OR cells or directory documents with specific content, but this seems much less likely.
I have been thinking about how we could make Tor (and browsers, and other processes, and OSs) less vulnerable to these kinds of attacks.
In general, some of the process-level defences against one or more of the above attacks are: * sign or checksum all security-critical data structures, * implement and check cross-certification, * don't rely on cached checks (or checks performed at load time) continuing to be accurate, * minimise time between checking validity and using the data, (this includes signatures, checksums, data structure consistency) * make the content of memory pages (including loaded files) less predictable, * make sure the hamming distance between trusted, valid inputs and untrusted, valid inputs is large, in particular: * register domains that are one bit-flip away from trusted domains, (or, alternately, mandate SSL, and pin certificates, and fix broken CA roots)
Some of the OS-level defences are: * turn off memory deduplication, * write and verify checksums on each page,
Some of the firmware/hardware defences are: * increase the RAM refresh rate, * improve RAM design, * use ECC RAM.
T
We've been keeping track of these attack classes on hypervisors: https://www.whonix.org/wiki/Advanced_Attacks https://www.whonix.org/wiki/KVM#Unsafe_Features Its great to design software that's resistant to adversarial conditions anyhow.
participants (2)
-
bancfcï¼ openmailbox.org -
teor