Not entirely sure why we need to update/protect most servers, since generally they won't be running untrusted code, right?
In principle you don't need to protect against spectre and meltdown if you can ensure that no untrusted code runs on a particular machine. How do you ensure that though? There are many many routes for that to happen, and it only has to happen once for it to completely invalidate your security model if you have no other levels of protection.
On a server you can run untrusted code by exploiting other vulnerabilities in server software such as buffer overruns. It's unrealistic to expect that all servers will have no such vulnerabilities in any of their software at any time. That's why operating systems implement many layers of protections to prevent those exploits from being elevated into even worse breaches that could leak sensitive data, provide local root access, and so on. One of the more significant protections that exists today is address space layout randomization, which makes it much more difficult for a buffer overflow exploit to result in immediate privilege escalation.
Meltdown/spectre make these sorts of issues much, much worse. They mean that absolute any vulnerability in any service could be exploited to read the entire contents of memory and deliver that to an attacker, including encryption keys, including passwords, and so forth. That's bad. You can essentially 100% guarantee that there will be some vulnerability in some service which enables a minor exploit, and you want to avoid having that minor issue become catastrophic through meltdown/spectre based attacks.
They are running on the cloud, and Meltdown / spectre means that exploits can escape a VM. This means you don't just need to trust your VM, but also any VMs you are sharing the hardware with.
Although this restriction on how the cloud provider is allowed to schedule your VMs probably would somewhat defeat the point of cloud hosting in the first place.
Out of curiosity, how many VM/container instances usually run on a physical host at any given time (for your typical cloud computing provider)?
Granted, that only works for workloads that are spread across enough small instances.
Even then, you don't need to trust your co-tenants. Updating the host (which your provider has already done, or which is anyway out of your control) is both necessary and sufficient to protect from VM escapes.
If the host is patched this doesn't matter (for VM escapes); however, for those on public clouds that will apply the host patching globally, you will be eating the performance degradation whether or not your workload cares about it. I don't think AWS et al will be offering a "run unpatched instance" option. Or maybe they will, this looks pretty devastating for some workloads; on the other hand, cloud providers could actually end up making a lot of money from this issue...
For spectre, the consequences of not applying those patches are not as bad but it wouldn’t surprise me if you could still do a lot of harm. PHP is somewhat sandboxes these days (by using chroot and what not) and meltdown/spectre could be used to escape the sandbox.
For my server, the attacker could probably read mosh‘s secret key which is used to authenticate mosh clients. Mosh is a “mobile shell” which allows is resistent toward network changes (including IP changes), is low bandwidth and extremely quick on Eadge connection.
An attacker can probably come up with many solutions where reading arbitary memory can be used to gain root access. Granted the low bandwidth aspect of this attack might make it difficult but far from impossible.
There will be processes outside a users control that run with elevated privileges, attacks that allow you to monitor the setup of these processes could prove risky to the overall security of a system.
Of course on shared servers this is going to be a nightmare.
there have been ~4600 privledge escalation bugs found since 1999. 250 a year. Almost one every day.
https://www.cvedetails.com/vulnerabilities-by-types.php
At this point we still won't have security and now we won't have performance either.
It's putting the cart before the horse.
The idea is to patch all known privilege escalation bugs.
It's rare for an attacker to rely on a single attack vector. They may get to the point where they only have limited access to running code, and want to break out of that sandbox. Spectre/Meltdown may be the route they take to do so.
Assuming bare metal. In shared hosting / cloud / VMs it is different.
But for servers, the application-level vulnerabilities that are needed in order to get meltdown or spectre attacks to run are already devastating. Take over a game server process and you own the in game currency and the scores and the ability to ban users, and probably user level login as well. And you have your pick of privilege escalation mechanisms already, probably.