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 no, you're not.
1. Running a service for other people (with shell access, or PHP/Python/whatever hosting). Not necessarily as a VPS or hosting provider, just "friends and family".
2. Spectre/Meltdown potentially make any RCE (say, in WordPress, or Django, or whatever) into root access.
It basically removes one level of "defense in depth".
@rysiek Until the patches land. This is just another arms race, no?
I always thought 2 was just a given; any RCE becomes root eventually.
In the medium term we may have to make the uncomfortable choice between "fast" or "secure", which sucks but isn't the end of the world.
The interesting take-away here is that virtualization, be it hardware or a JIT, is not as safe as we hoped (but still probably safer than some people feared). Sandboxing is hard, we already knew that but hoped for magic.
@HerraBRE no, not all RCEs become root. The fact that we have multi-tenant systems serving tech-savvy users without these users constantly getting root on them is proof enough. :)
It's always an arms race, yes.
Sandboxing is hard, and making decisions where we want to be on the security<->speed spectrum is hard also. We need to dial back on speed and up on security, but there are no incentives to do so, usually. That's the main problem, IMVHO.
@rysiek I go around assuming they're not constantly getting root mostly because they're not all malicious / capable... 😉
But it's an interesting class of bugs, that's for sure!
@HerraBRE Only that the tinfoil hat brigade are suckers!
Everyone knows that tinfoil hats only make it easier for the government mind control rays, you need a faraday hat to be protected.
@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 I didn't say never. I said it was a best security practice, which it is.
I'm well aware that lots of people (myself included) prioritise other things above absolute security.
When have SaaS and PaaS and IaaS not been problematic for privacy and security? People who care (banks, for example) do this in 2018 the exact same way they did it in 2008 and 1998.
Own hardware or lease entire machines. It's not rocket science, even if your employer would like us to think otherwise. 😉
Did AWS update faster than we have? Sure. But since we're using bare metal and do not have anyone else on the same hardware, we did not even need to patch immediately.
@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? https://aws.amazon.com/security/security-bulletins/AWS-2018-013/
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.
@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.
@rysiek @HerraBRE It's impressive that you've built a data centre that withstands the NSAs and FSBs of this world. If that's your threat model and you've countered it, that's pretty impressive. You must be confident that you've countered that threat better than the cloud providers can, too, which is all the more impressive. I don't know many smal businesses that run data centres capable of resisting the 3-letter-agencies.
Nor are we confident we can always protect stuff (on the technical level) better than large providers. Not using their services, however, solves other (non-technical) issues.
My point is this: security people often reach for the agency threat when they talk about reasons to use bare metal. It's the ONE threat that bare metal seemingly solves. But bare metal ONLY solves that threat if you ALSO do a long list of other expensive security controls. So, given that you probably AREN"T defeating the agencies, what's the point of bare metal? The NSA/FSB threat isn't an interesting security discussion. Nobody (on here) is really designing to defeat them.
There will be more bugs like this.
Security professionals know this and have known for a long time. Thus my claim it was a standard best practice, albeit one that has costs not everyone could justify.
That math has shifted now, more people will justify the expense. Not all, but more.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!