So... and .

Both are triggered by malicious code running on the same hardware as you.

Mitigation means don't put anything important on shared hardware (read: avoid VPSes) and run NoScript or the equivalent in your browser.

Weren't those security best practices already?

Yes, this is a nightmare for VPS providers and worrying for those who placed their trust in virtualization. But the tinfoil-hat brigade has been assuming such bugs existed for ages.

Am I missing anything?

@HerraBRE One OS instance per hardware has been a "security best practice"? No. I don't think it was. And ordinarily it shouldn't be.

@paco The security best practice I speak of is:

"Don't share hardware with untrusted strangers who can run arbitrary code and try to attack your hypervisor or local network."

Of course you should use all the compartmentalization tech that is appropriate for your use case. Even if they can be attacked, it raises the bar.

@HerraBRE Never share hardware with strangers? Seems too blunt.

At face value that would prevent using any cloud infrastructure at all wouldn't it? Seems like it might make SaaS services problematic too.

I don't think I've seen that sort of principle put forward as a best practice. I don't see how you could follow that principle in 2018.

@paco @HerraBRE hi. We keep all sensitive stuff on bare metal. In 2018, just like we did in 2017. And 2016. And before.

So, yeah.

@rysiek @HerraBRE
Why? To what benefit? What attack is on your threat model that is defeated by that design choice?

@rysiek @HerraBRE The date on this advisory is yesterday, and note that at that time 90+% were already done worldwide. Who patches faster than that? aws.amazon.com/security/securi

@paco @HerraBRE that is completely missing the point.

The point is not how fast AWS patched their systems for this. The point is since we were using bare metal in the first place, we were basically not affected in any way.

As in, there was no possible malicious co-tenant on the same hardware that could have extracted anything from our memory space.

Because all memory space is our memory space.

On our bare metal.

@HerraBRE @paco you do realize, I'm sure, that the vulnerability was there way before GPZ discovered it and vendors started working on the fix.

And during that time AWS, Azure, all other Cloud platforms were vulnerable, and their users open to malicious co-tenants.

But again, not on bare metal.

@rysiek @HerraBRE I understand it was there for 20 years. Like the OpenSSL and bash bugs that were old when they were discovered. Do you think it was being actively exploited but somehow nobody knows? It's all been hushed up? Or was it perhaps not actually exploited? I have no idea, myself. But it seems hard to believe that it was being exploited a lot for 6 months, but nobody knew.

@paco @rysiek We'll probably never know, unless some too-big-to-keep-secrets agency was using it and proof gets leaked.

If you've got an 0-day like this, you will keep it real quite and use it sparingly on high-value targets.

· · Web · 0 · 0 · 0
Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!