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 well, for one: https://meltdownattack.com/
@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/
@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.