[vfaronov]

I have a hunch that the era of side-channel attacks is only now dawning, and that we should expect many more painful exploits and cumbersome mitigations in the coming years.

What do people more knowledgeable in the field think about this?

[xigency]

What about users who only execute trusted code?

All of these attacks assume you are running something you don't trust on your CPU, whether it is another user's program, a non-root executable, or a JavaScript program from a website.

When do we stop hacking processors, kernels, and compilers and revisit our assumptions of what we can and can't do securely.

[pjc50]

Define "trusted"? Who do you trust to do your verification, and how much does it cost?

[xigency]

Well, critical applications, like flight systems, run on a different ecosystem and are verified. (And it costs a lot.)

But my usecase might be a physical computer that isn't networked which does data science with some programs and prints out results.

These patches are focused at Amazon and cloud providers that are in the business of running separate individual's applications on the same machine.

In the consumer world, the slope would be browser scripts and user applications that aren't running as super. But even then, do you download and run software that you expect might steal information or damage your computer?

These are fundamental security questions. Creating rings and sandboxes are what create the assumptions of privacy and security.

[dingo_bat]

Oops I basically wrote an identical reply before reading yours.

[Klathmon]

I'm not more knowledgeable than you, but I think I agree.

side channels have always been some of the most insidious exploits. Many are basically un-solvable (timing attacks are always going to leak some information, and compression is basically completely at odds with secure information storage), many more are easily enough overlooked that it would be easy to maliciously include them without raising any eyebrows, and the "fixes" for them almost always murder performance.

I think the only real fully-encompassing solution to this is a redesign in how we use computers. Either a massive step backwards on performance and turning off most automatic "optimizations" until they can be proven through a much more rigorous process (both in compilers, and in hardware), or a significant change in how computers are architected adding more hardware level isolation for processes and systems running on the machine (just daydreaming now, but something like a cluster of isolated micro-CPUs that run one application only).

[dingo_bat]

How about not running untrusted code? That seems to be much easier to do and won't kill performance. Kill js on the web. Run only apps signed by Microsoft. Develop ML based malware fingerprinting that can recognise timing attack patterns. Throwing OO execution away shouldn't be an option in the long term.

[Klathmon]

It's not just "untrusted code" any more.

The "true secure" way is not running any untrusted code, not connecting to any untrusted networks, and not accepting or storing any untrusted data.

At that point you can't run a computer. It's just not an answer to say "don't let bad things in" because bad things are always going to get in.

And with side channel exploits getting more and more common, and with them being worse and worse, running any code on your machine is basically giving that code any and all of your data on the machine...

Telling users (even highly technical users) to "never ever run any untrusted code ever, and if you mess up once and run untrusted code you have completely ruined the trust of the whole machine and need to start over from scratch while assuming all of your data has been compromised" is not only infeasible, it's impossible. If this is the case, we have lost the "security" game.

It's easy to say "throwing oo execution away" is an overreaction, but if it's necessary to allow multiple programs to run on one machine without them all having what amounts to full access to one another's information, then it might be necessary. Already we know that we can't use compression with encryption, we can't use any kind of "exit early" with most kinds of encryption. It might just be that OO execution is fundamentally opposed to secure computing. At it's core, it's letting the processor do different things depending on what it can see is coming, it's almost a definition of an oracle! That's always going to be a very dangerous game to play.

It could even just be that CPUs need a "secure computing" mode, or maybe even a secure co-processor that disables all of these optimizations. But at the very least, I think changes are going to be necessary, and a 15% perf reduction might be the least of our worries.

[xigency]

Eliminating out of order execution completely would result in much more than a 15% performance reduction.

[Klathmon]

That's what I was trying to say a bit more tongue in cheek...

[smt88]

"Kill JS on the web" is easy and only mildly inconvenient using NoScript, but that doesn't mean most laypeople are going to do it.

Chrome and FF need "execute JS" to be an explicit per-site permission, similar to the permissions model of native smartphone apps.

Google will never do this because they're an ad company and care more about targeting ads than protecting Chrome users.

[danjoc]

Surprisingly, this is how chromium(chrome?) works. You can set it to block JS by default, then you get a <> symbol in the address bar. If you want to enable JS on a domain, right click it and enable. Now all the JS on that domain loads normally. It isn't as fine grained as NoScript, and there's not an easy way to temporarily allow. However, it's probably more normie friendly than NoScript that way.

[rphlx]

> need "execute JS" to be an explicit per-site permission

I would personally like that, but it's too optimistic to think that the average user would gain much security from it. Most of them will discover that things work fine when they click OK/Accept, and sometimes break when they don't, and so they become conditioned to just click OK/Accept all the time to avoid potential hassle. So in the end it just reduces productivity without increasing security much.

[bobajeff]

There is no chance JavaScript/WebAssembly will get disabled in browsers. However, it is possible things like Zero-rating, Certification Authorities, Google AMP and Facebook Instant Articles could eventually help to lockdown the web to only trusted domains.

However this wouldn't completely solve the issue (see Google Play Store).

[Dylan16807]

> I think the only real fully-encompassing solution to this is a redesign in how we use computers.

You can do a lot by separating these speedup mechanisms across security boundaries. The biggest factor that makes this hard to mitigate is in-process security boundaries. Total isolation between processes is neither necessary nor sufficient.

[rsync]

"What do people more knowledgeable in the field think about this?"

https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

(from 2007)