Fwd: [tor-dev] Browsers, VMs and Targeted Hardware Bit-Flips

grarpamp grarpamp at gmail.com
Sat Nov 19 21:20:04 PST 2016


https://www.whonix.org/wiki/Advanced_Attacks
https://www.whonix.org/wiki/KVM#Unsafe_Features

---------- Forwarded message ----------
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.

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


More information about the cypherpunks mailing list