When will people realize that the problem is running untrusted code on the same CPU as code that needs to keep secrets?
The issue is with untrusted speculative instruction streams which can be influenced by untrusted code and/or untrusted data. NetSpectre was a remote kernel read primitive entirely from malformed network packets, no untrusted code needed, and no data other than network packets coming in over the wire.
edit: to be clear, I just learned about retbleed five minutes ago, so I'm definitely not promising core scheduling mitigates it. I do think core scheduling is a good idea in general.
[1] https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/c...
That's how I feel though some days, tbh.
15 seconds later
(I'll admit: I didn't even notice until just now that it was you who'd made the parent comment, and I feel maybe a little bad about the tone I took. But I'm still right!)
1. Most hosts have some secrets. For example, client credentials. That's hard to avoid unless you just don't do auth at all.
2. Most hosts let users ssh to them.
3. What you've described is the cloud provider/ PaaS model.
4. It's not that easy to just "keep untrusted code" out. Like, what if an attacker exploits an exposed service and then wants to privesc?
Single-user systems can be affected by these, but they can be affected by more direct attacks.
uMatrix permits enabling or disabling JS (and other website features: images, CSS, media, frames, XSS, ...) by domain or subdomain, including default allow/deny permissions should you choose.
You can also temporarily enable or disable specific permissions, and save those changes permanently should you choose.
It's fiddly, but good fiddly.
That’s the point: you can’t just pile every website into the same zone, and if you did pile them into the same zone, then using a different password for x.com and y.com is to some extent pointless because x can observe y’s password input and vice-versa.
(disregarding the fact that in current computing architectures “just put all the untrusted stuff on one core” is probably an insufficient solution due to shared caches anyways, no indeed nothing in this attack requires “sharing a core”)
Regardless of your programming language, the low-level machine code is vulnerable. At some point, passwords and other sensitive data is in the memory, and by using these exploits, they can be exposed.
Alternatively, let's be sure that the attackers are not running untrusted code.
If you only run code you trust, then (assuming your trust was placed in it properly) it won't steal anything from you.
Also, if you are running a web browser with JavaScript turned on, that is effectively another user able to steal your junk.
I think people will realize when someone offensively applies this in the civilian space. The money is there waiting for those of you who want a few hundred million USD worth of crypto. The test of the exploit will be in the exploiting.
ActiveX allowed the execution of unsandboxed x86 code from controls embedded in webpages and was enabled by default in Internet Explorer, the dominant browser of the time.
Javascript caught on because it's at least interpreted and sandboxed, a huge step up from what ActiveX was.