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

[bancfc at openmailbox.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.