Hacker News Reader

Comment by gautamcgoel | Hacker News Reader

A lot of these discussions focus on servers. What about us Plebs, who only run desktop machines? What should we do?

Leaving SMT enabled is most likely what you want to do. It's more performance, and the attack vector on a desktop machine for this is incredibly small. You'd need to run untrusted code (not hard, JavaScript is everywhere after all) but that JS code would need to have something to attack on a neighboring thread (unlikely) and know to attack that neighboring thread (even more unlikely) and not get mitigated by any of the browser spectre mitigations that have been in place for a while now (again, unlikely)

I disable Spectre/Meltdown mitigations on all my Linux machines, that's how worried I am.

same. If someone wants to breach me they are going to use a zero day anyway, or use the days between zero and when I apply the patch. Or breach my windows box, or intercept a package or something. SIM swap, etc.

Now if only I could figure out how to disable Windows Defender reliably.

How I feel about this all: https://xkcd.com/538/

I'd have thought that a desktop machine was more likely to run untrusted code than a server.

And then god said "let there be Docker!" ...

These days I mostly have no idea what the hell any of my equipment is running. There is a whole industry that popped up to write tools to work out what the hell you are running and work out how screwed you are. Doesn't feel healthy to me.

Unless you're a cloud provider/ a SaaS that provides remote code execution, that's likely true.

… and you will do nothing, because you can do nothing.

Well... aren't these attacks only a concern if you have adversarial code running on adjacent cores? So for a desktop user the threat model really doesn't change. Just do your best to keep malicious programs off of your machine. If someone can already run a speculative execution attack against you're local machine, there are much easier attacks to run.

> Just do your best to keep malicious programs off of your machine.

So don't visit the web then.

How closely have you followed the layers of mitigations which the major browser engines have implemented? I think a more interesting form of this question is asking how often people are exposed to malicious code which isn't covered by the browser sandboxes.

Is there any record of web-based attacks like this?

Not AFAIK. There are contrived PoCs of browser based Specter exploits, but no practical examples have been discovered.

Browser vendors have been pretty quick to add mitigations, disable attack surface, etc. Someone comes up with a new way to attack systems via JS, but vendors are all headed in a safer direction.

Disable JS by default.

Every web page you visit allows a “malicious program” to be run on your machine.

if you arent running vms, you can chill.

No you can't, attacks like spectre are exploitable from javascript.

Has anyone seen an attack in the wild, though? Ever?

People were doing POCs before the browser makers nerfed the hell out of timing APIs especially from web assembly and autoupdate distributed the nerfs out.

What does 'nerfed' mean in this context?

'Nerf' is a term used for when game developers update a game and reduce the effectiveness of something. 'My sword attack ability was nerfed in the latest patch'. In this context I suppose the API capabilities was reduced in browser updates.

In particular, the word is derived from a brand of toy foam arrows. Basically, it refers to negating the possible damage of something.

Lower the precision by adding random noise.

Browser manufacturers changed the behavior of APIs like performance.now() [0] to add slight rounding 'errors' or limit the granularity of timing functions. That function used to report on the microsecond level in (most) browsers, but now is generally limited to around 1ms due to timing attacks.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Performance...

surely high precision clocks can be constructed via busy waits or random api calls that hit hardware to do things with fixed latency, no?

All those can be limited, because thankfully JS is not multithreaded (otherwise you could do busy-loop timing).

Yes, like the SharedArrayBuffer that browsers disabled. There are probably roughly infinite ways to construct clocks. Closing the obvious leaks has been a stop gap while other mitigation techniques are rolling out, like site isolation.

Reply on news.ycombinator.com