7

This article demonstrates a devastating Javascript-based cache timing attack that allows for cross-VM tracking of mouse movements and other activities by web pages.

Is the only way to prevent cache-based snooping for the kernel to (1) never run mutually-distrusting processes on the same CPU die at the same time and (2) flush all caches on all context switches between mutually-distrusting processes?

Demi
  • 769
  • 1
  • 4
  • 11

1 Answers1

1

Direct answer

Did you aleady read page 11 and 12 of this document, chapter 5.1, about Prevalence of Vulnerable Systems and 5.2: Countermeasures?

If your system is really vulnerable, then yes, you have to flush cache of sensible information before accessing suspect web pages.

But if your cryptographic tool uses non-cached memory, they are not vulnerable...

You could use NON Intel or single core CPU... or ensure no Sandy Bridge, nor Ivy Bridge and no Broadwell micro-architectures are used in your hardware.

And keep your Intel-based servers away from optimised JavaScript.

Second time reflection

For my understanding, this paper is more a proof of concept than a exploit cookbook.

I mean, if this was possible in this specific configuration, by using this method and optimised javascript, We have to keep in mind that:

Cache attack is possible.

Regardless of requirement for this demonstration.

In fact, new multi-cores processors are insufficiently protected, due to performance challenges.

And new optimisation at libraries level could make some unattended backdoor.

This exploit is hard to reproduce, but show that if processors constructors don't care, futur could become hazardous.

F. Hauri - Give Up GitHub
  • 4,597
  • 2
  • 19
  • 32
  • 1
    That's not practical for almost all applications, due to either requiring incredibly expensive static RAM, high-density MRAM (which doesn't exist yet), o accepting a massive performance hit. And it is not just cryptography: the attack given retrieved mouse and usage data, not crypto keys. – Demi May 24 '16 at 05:53
  • At chapter 5.2, you could read: *are possible because of a confluence of design and implementation decisions starting at the micro-architectural level and ending at the Javascript runtime*. So for making this impossible, you just have to break this chain! – F. Hauri - Give Up GitHub May 24 '16 at 06:16
  • No, this is a cache attack. Swapping is not required. – Demi May 24 '16 at 06:16
  • Changes at the JS runtime level don't solve the general case (consider a VM that wants to spy on its host). Hardware changes have a perf penalty and cannot be done on hardware already in use. – Demi May 24 '16 at 06:20
  • In the other side, this paper is more a proof of concept, than a exploit cookbook. I mean, If this work in this way with this kind of architecture. You could think that same kind of listenning are possible with other architecture even in an other way, due to alway smaller design and confluent methodology. – F. Hauri - Give Up GitHub May 24 '16 at 06:22
  • Yes, I think next step is to understand and implemant *`apparmor`* with strong configuration... – F. Hauri - Give Up GitHub May 24 '16 at 06:24
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/40205/discussion-between-f-hauri-and-demetri). – F. Hauri - Give Up GitHub May 24 '16 at 06:33