Comment by tux3 | Hacker News Reader

Comment by tux3 | Hacker News Reader

Parent Full thread

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.

so 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?

There 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...

The fix is simple, don't allow access to clocks or timing information in anything other than the microkernel that runs the OS.

That would break so many things.

Proper 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.

I 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.

You 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.

You 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 is not disabled in all browsers. It was briefly disabled at disclosure time of the first Spectre vulnerabilities, but as browsers moved to site isolation (one process per origin), they have reenabled it.

Reply on news.ycombinator.com