It's a way deeper problem than untrusted code, as NetSpectre [0] showed.

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.

[0] https://gruss.cc/files/netspectre.pdf

This is about as trenchant an analysis as "when will people realize that the problem is computers?". The constraint we work with when securing systems is that we don't get to rearchitect the entire world; that's what makes systems security hard.

Yes, that is indeed the original sin. See Morris’s Three Laws Of Computer Security: do not own a computer, do not turn it own, and do not use it.

> when will people realize that the problem is computers?

That's how I feel though some days, tbh.

As a security guy, you’re stuck with the world as it is. But as a mere user, I can certainly complain about the direction computing has gone.

Of course. I'm just saying, it's a banal point to make, and certainly not one that will produce a useful, interesting, or curious conversation.

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!)

Systems security people can complain too, but just like they can’t change things neither can you :(

At least don't share the same core. There's gotta be some limit.

IIUC on Linux you can enable CONFIG_SCHED_CORE/PR_SCHED_CORE to realize that idea. [1] Some caveats may apply...

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

Is that even enough? Hyperthreading let some of the earlier spectre exploits work faster, but as long as there's some shared cached between two cores (L2 or L3), that's enough for timing variations to leak what's in that cache afaik. Maybe it's enough for this attack (unsure), but I don't think it solves speculative side-channel leaks in general.

Is that the problem?

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?

The problem is cloud, basically, where you're defined by running various VMs on the same CPU.

Single-user systems can be affected by these, but they can be affected by more direct attacks.

on clouds the only problem is HT. on vm providers it's cpu overcommitment (clouds rarely do that)

I only have so many CPUs, and I visit more websites than that.

Consider disabling javascript on websites by default and only allowing it on those that you trust. e.g. uBlock origin has that built in. You'd be surprised how much still works perfectly fine and of cause, which sites break for no good reason.

I want an extension that disables JavaScript by default and then allows me to enable and disable JavaScript for the current site that I’m visiting (and all of its dependencies; I don’t want to deal with enabling it also for its cdns etc) with only one click and then remembers my setting. Does that exist?

Umatrix from the author of ublock origin can do this. Not with a single click (it'll take two, one to enable and one to tell it to remember) but it's very close.

https://addons.mozilla.org/en-US/firefox/addon/umatrix/

Clarifying, for those unfamiliar with it:

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.

You can do that in uBlock Origin, just enable advanced mode then you can block 1st + 3rd party scripts across all domains in two clicks..

NoScript used to do it in 1 click. Now that it's a Web Extension, it takes two.

So you use the same password for SO and HN?

I have no idea what that means relative to this conversation. Either I'm out of my depth or we're talking past each other. Either way, no big deal.

If you use different passwords, you must believe they are in different trust zones, and the usual time sharing methods won't work, in light of this and many other attacks. You will need separate CPUs as suggested by rayiner.

You can run trusted code on one processor and untrusted on another. The untrusted processor must not perform speculative execution. It'd be slow but should solve the presented conundrum.

Unfortunately, being slow is just not acceptable in a decent portion of scenarios. Web developers won't start writing 5x faster sites, and cloud providers won't like needing 5x more hardware to serve the same amount of virtual CPU performance. (5x being my random guess of the performance decrease from losing speculative execution & co; it'd likely be even worse, especially combined with the fact that manufacturers would have to design a completely new chip)

Their point is untrusted code can still have private info (I don't want a random website to be able to steal my private key or my info like credit cards or password in other tabs), so you need a new core for each website, which is obviously impractical.

My point is that if you disable speculation on the insecure core then the websites can share without this class of exploit being a risk factor. There my be other vectors for accessing the data of colocated processes.

They aren’t in different trust zones, because there’s nothing to trust in either of those. The reason for using different passwords is to minimize the losses when they leak.

They need to be in different trust zones unless your willingness to enter a credit card into any website means you’re willing to allow every other website you may be visiting to observe that input. Ditto viewing bank information etc.

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”)

I’m not entering credit card info though. And even if I did, it’s not very security-sensitive - in the worst case the bank will give me back my money stolen from the card.

If you truly never enter credit card info on the web, or truly have zero expectation that other tabs shouldn't be able to spy on that credit card info when you do, then frankly you're so outside the range of normal people's expectations and behaviours that I don't think basing security architecture around what you do or don't do makes any sense whatsoever.

I am unclear on how this relates to untrusted code.

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.

> I am unclear on how this relates to 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.

But in most environments, you as a user are not in total control of what is running. If you are in the cloud, other users in unrelated virtual machines can steal your junk.

Also, if you are running a web browser with JavaScript turned on, that is effectively another user able to steal your junk.

Yes that is true. Untrusted code in general computing environments is basically inevitable.

There's an FTX customer with nodes accessing via API keys that control hundreds of millions of dollars of crypto. That customer has Spectre/Meltdown mitigations off and will probably run with Retbleed mitigations off.

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.

Really, the problems all started from secrets existing in the same universe as untrusted actors.

Back in the 2000s pretty much everyone knew not to run un-trusted code ("don't open that email attachment"). But then javascript happened and the utility was so profound everyone decided to forget.

I think you're looking at the past with rose-colored glasses.

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.

People have been running code having different security levels on the same hardware since the early time-sharing systems (1960's).

Can't you mitigate just the Javascript VM? JS is a slow scripting language anyways. Seems like a waste to slow down the entire system.

Even if it's far from obvious to an average person that JavaScript is a pwn vector, I think you're more correct than not. You need enough isolation to run untrusted code. If JS code can still exploit CPU bugs, then clearly more isolation is needed one way or another.