Hacker News Reader

Comment by kilo_bravo_3 | Hacker News Reader

Despite the protestations of l33t Cyberhaxxing Z3r0 Cools everywhere, you only have to turn off hyper-threading if you are sharing a machine with someone you don't trust.

If someone is on your machine and you don't know it, they don't have to use side-channel attacks.

They'll can just use any of the thousands of other ways of privilege escalation to read the super-secret information you have stored in RAM, or find it when it is written to disk.

The OpenBSD folks disabled SMT by default because of TLBleed.

A non-datacenter/cloud user disabling SMT to avoid TLBleed is like a normal person carrying a fireman's rescue saw around with them 24 hours a day in case they get into a situation they have to saw themselves out of.

View on HN

> Despite the protestations of l33t Cyberhaxxing Z3r0 Cools everywhere, you only have to turn off hyper-threading if you are sharing a machine with someone you don't trust.

If you're reading this reply, you probably automatically executed `hn.js`. Are you _sure_ you know what it does?

Unless you're browsing the web with Javascript completely disabled, and you also don't have any applications that automatically update themselves from a remote source (are you _sure_ you know what those various auto-updaters are downloading?), you're running untrusted code on your machine.

Perhaps you don't particularly care about that risk, or you don't feel the risk is severe enough to warrant the performance hit, which is fair, but the risk is there nonetheless.

Are you aware of any spectre POC that in JavaScript you can break out of that sandbox and do anything worth while?

Yeah, my understanding is that browsers added mitigations for this sort of stuff - so I'm curious about it too.

i believe that the browsers fuzz your timings now which is what spectre heavily relied on. i think people thinking JS+Spectre in the wild are misled especially since 99% of people run with mitigations enabled, why would someone try to exploit it on a browser

Spectre does not allow write access to unprivileged memory; you need another exploit for that. Spectre allows read access to essentially all of the containing process's address space. This is enough for just leaking secrets, but can also assist with other vulnerabilities, e.g. reversing address space randomization in order to figure out where to write in memory with the other vulnerability. It makes all write exploits more dangerous.

If I should disable hyperthreading because of a hypothetical risk from an experimental proof of concept, shouldn't I also throw my PC into a dumpster because I don't know if the microcontroller controlling my LCD isn't also amplifying and Van Eck'ing my desktop to Chinese and Russian superspies waiting in a van outside?

After all, I'm not _SURE_ I know what it's doing.

Perhaps you don't particularly care about that risk, or you don't feel the risk is plausible enough to warrant the loss of one's computer, which is fair, but the risk is there nonetheless.

Why would a l33t haxxor waste their time on an esoteric and academic attack when they can just get their victim to click on something?

Because otherwise it's kind of hard to get system root from a single click in a (somewhat) sandboxed environment.

AFAIK hyperthreading issues are related to some narrow set of bugs (zombieload?), which are extremely difficult to exploit, at least not in a browser. Correct me if Iam wrong.

Hyperthreading (SMT) is the most fruitful vector for side-channel leaks because so many processor resources are shared between the threads. This was the case even before Spectre.

Conceptually it's also the easiest vector to mitigate in the OS--simply schedule processes in different trust domains (e.g. different UIDs) on different physical cores. This is what good VM hypervisors do. You'll never be scheduled on a physical core in parallel with another AWS tenant, which is why the minimum vCPUs on AWS is always 2. But traditional kernel schedulers (Linux, macOS, Windows, et al) and user space APIs for this mitigation are still nowhere in sight.

Right, I understand it is not good in the cloud environments, but how exactly would you exploit it on a desktop Linux computer?

JavaScript and WebAssembly. See MDS (https://en.wikipedia.org/wiki/Microarchitectural_Data_Sampli...), a non-exclusive class of vulnerabilities of which ZombieLoad was but one proven exploit, Portsmash (https://www.theregister.co.uk/2018/11/02/portsmash_intel_sec...), and others.

Here's a good paper (pre Spectre) that surveys various timing attacks and how they relate to specific architectural features: Qian Ge, Yuval Yarom, David Cock, and Gernot Heiser, "A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware", https://eprint.iacr.org/2016/613.pdf.

Or.. if you run untrusted code, such as a web browser with Javascript enabled.

Reply on news.ycombinator.com