[Cryptography] 33C3: cash :-) attacks !

[Henry Baker]

FYI --

https://media.ccc.de/v/33c3-8044-what_could_possibly_go_wrong_with_insert_x86_instruction_here

https://cdn.media.ccc.de/congress/2016/h264-hd/33c3-8044-eng-What_could_possibly_go_wrong_with_insert_x86_instruction_here.mp4

(55 mins; 327 MBytes)

"What could possibly go wrong with <insert x86 instruction here>?
Side effects include side-channel attacks and bypassing kernel ASLR"

Clémentine Maurice and Moritz Lipp 

"Hardware is often considered as an abstract layer that behaves correctly, just executing instructions and outputting a result.  However, the internal state of the hardware leaks information about the programs that are executing.  In this talk, we focus on how to extract information from the execution of simple x86 instructions that do not require any privileges.  Beyond classical cache-based side-channel attacks, we demonstrate how to perform cache attacks without a single memory access, as well as how to bypass kernel ASLR.  This talk does not require any knowledge about assembly.  We promise."
-----

Abandon hope, all ye who cache here!

Why care about encryption, when you have devastating attacks such as these?

These new timing attacks enable 500KBytes/sec covert channels between "independent" virtual machines, reverse engineer virtual memory -> physical memory maps, etc.

You can create a completely benign-looking app that can be downloaded into your Android phone, but which can still snoop on your typing.  Your Signal app can be as clever as it pleases, but that "calculator" app or that "weather" app might still read everything that you type.  If the same organization designs both a picture organizing app (having only permissions for accessing pictures) and an app that requires access to the Internet (but not your pictures), then they can covertly communicate to put all of your sexy selfies on the Internet.

I.e., there are NO benign apps!

Are there any *software* countermeasures for these types of attacks, or do we have to wait for the next generation of hardware?  Even if we do wait, do the HW people even know how to build HW that doesn't have these types of vulnerabilities?

Do we need to have completely separate caches for each thread and/or process?

This problem reminds me very much of the vulnerabilities introduced through *data compression*; duplicate portions of a message can be detected because the compressed message is shorter than if there were no duplicated portions.