Hacker News Reader

Comment by userbinator | Hacker News Reader

The easiest prevention is to stop running untrusted code, or don't start doing so if you're not already.

The "elephant in the room" with all these attacks starting from Spectre/Meltdown is that an attacker has to run code on your machine to be able to exploit them at all.

To the average user, the biggest risk of all these side-channels is JS running in the browser, and that is quite effectively prevented by careful whitelisting.

As you can probably tell, I'm really not all that concerned about these sidechannels on my own machines, because I already don't download and run random executables (the consequences of doing that are already worse than this sidechannel would allow...), nor let every site I visit run JS (not even HN, in case you're wondering --- it doesn't need JS to be usable.)

View on HN

I think that's a cop out. A system should be secure enough to isolate untrusted code.

For some systems that's definitely the case. Not all systems require this (not all companies can afford to replace/patch their current hardware)

A friend and coworker of mine had a saying "Speed Kills" about trying too hard to make things fast while keeping the system robust. You most certainly can make more secure systems, as the merely superscalar and less intense CPUs are, but they're significantly slower.

All depends on your threat model; to take one extreme, if you're crunching numbers with your own optimized numeric code, the issue of untrusted code of "random JavaScript off the net" is not an issue. And I doubt many mainframes are used to casually browse the net ... I certainly hope not at the same time they run the night's financial transactions!

With any cloud computing, they very well could be.

Good point, I was thinking in the context of owning your own (super)computer or mainframe and having control over what ran on it. In the cloud, which to us implies running in a VM with other tenants vs. for example dedicated machine(s) with other services bundled in, anything goes.

The problem of running untrusted code is that the whole stack is a potential attack vector. From CPU to Javascript JIT compiler. Systems will never be secure enough to fully isolate untrusted code, because (1) people make dumb mistakes; (2) the incentives of most hardware/software vendors are profit, not security; (3) people have other priorities than security, e.g. performance.

At any rate, this is the world that we live in. Advise your non-tech friends to run updates to get the latest microcode and software mitigations. Install uBlock for them and block possible attack vectors aggressively (ads, trackers, etc). As a technical user, it's best to disable JavaScript completely by default and enable trusted third party JavaScript using e.g. uMatrix. Of course, this has other benefits too: creepy companies don't get to follow you around.

> A system should be secure enough to isolate untrusted code.

In a dream world. It's become obvious that our general-purpose systems are far too complex to be proven secure, and trying to run untrusted code on such a foundation is going to turn up vulnerability after vulnerability after vulnerability. It is madness.

Reply on news.ycombinator.com