5 ms·
I'm simplifying a bit (edit: quite a bit =]), but the way these attacks work is generally by exploiting the difference in timing between something being in cach
by tux3 6y ago
I'm simplifying a bit (edit: quite a bit =]), but the way these attacks work is generally by exploiting the difference in timing between something being in cache, and something not being in cache. Or some resource being contended vs not contended.
If something is in cache, and you also have access to that cache, accessing that thing will be fast and few CPU resources will be used.
So you can tell that something is in cache. And you know you didn't put it there. So some other thread that you're sharing a CPU core with must have put it there.
To exploit those attacks, you're going to intentionally watch the other thread as it, for example, (speculatively) takes a branch, and either puts something in cache or doesn't. Now you know whether the other thread (speculatively) took a branch or not! Just from measuring timings of the cache.
From that, you work back to what the branch condition (that was still only speculatively executed) must have been, and if this branch is based on (speculatively loaded) data, you just leaked one or more bits of the data.
Suddenly, things are not speculative anymore. You guessed data that wasn't yours, because speculatively using it had an effect on the cache, and you could measure that effect. Here, they use the micro-op cache (I haven't read the paper, so I don't know the details, but this is broad strokes).
Any mechanism that you can use during speculation, and that you can extract timing information from is potentially a problem. And these are everywhere.
That's why the Spectre problem is so hard to fix now that pandora's box is open.
- fnord77 6y agoso something say, sandboxed (like in a browser running webassembly) could get at non-sandboxed data? Or something in one VM getting at data from a different VM?
- DoomHotel 6y agoThere are examples of straight JavaScript exploits that allow a website to read memory from anywhere in the process its code is running in. https://cacm.acm.org/magazines/2020/7/245682-spectre-attacks/fulltext https://cacm.acm.org/magazines/2020/7/245682-spectre-attacks...
- mikewarot 6y agoThe fix is simple, don't allow access to clocks or timing information in anything other than the microkernel that runs the OS.
- jeffbee 6y agoThat would break so many things.
- mikewarot 6y agoProper multi-level security doesn't allow access to the clock in anything other than the top level. You could just have a monotonically counter that is periodically synced to reality every minute or two.
- jeffbee 6y agoI must be misunderstanding what you are suggesting, since what it seems like you are suggesting would never work. High-resolution timing information is available to user applications via numerous APIs today. Hyrum's Law, and common sense, tell us we can't just lose this feature of operating systems and expect applications to work.
- titzer 6y agoYou can construct a high resolution timer from shared mutable memory and multiple threads. It's simple. One thread increments a counter, and the other thread reads it.
- xucheng 6y agoYou don't need OS to build a very precise clock for the purpose of exploiting timing attack. That's why SharedArrayBuffer[1] is disabled in all browsers. Moreover, not every side channel attack relies on timing attack. For interested readers, there is a paper titled "Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript", which discussed a variety of ways to build high resolution clocks. [1]: https://security.stackexchange.com/questions/177033/how-can-sharedarraybuffer-be-used-for-timing-attacks https://security.stackexchange.com/questions/177033/how-can-...