Pretty much what I predicted here: https://news.ycombinator.com/item?id=16054674
> Sounds like servers handling lots of small UDP packets would be hit pretty hard.
CPU Usage Differences After Applying Meltdown Patch at Epic Games
21–30 of 296 posts
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#22>We wanted to provide a bit more context for the most recent login issues and service instability. All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability. We heavily rely on cloud services to run our back-end and we may experience further service issues due to ongoing updates.
So they are saying "you can't log in because we're too cheap to rent more servers now that this patch has increased CPU usage"
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#23>We wanted to provide a bit more context for the most recent login issues and service instability. All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability. We heavily rely on cloud services to run our back-end and we may experience further service issues due to ongoing updates. So they are saying "you can't log in because we're too cheap to rent more servers now that this pat…
Resolving scalability issues is not as simple as "rent more servers".
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#24Earlier quoted context omitted.
The reason for doing so is minimising the risk if an attacker breaks into a server. This is also why systems like ATMs should be patched. Untrusted code execution on servers and ATMs may not be the norm, but it's far from impossible.
couldn't they just use a myriad of other priveledge escalation bugs? 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.
> "couldn't they just use a myriad of other priveledge escalation bugs?"
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.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#25>We wanted to provide a bit more context for the most recent login issues and service instability. All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability. We heavily rely on cloud services to run our back-end and we may experience further service issues due to ongoing updates. So they are saying "you can't log in because we're too cheap to rent more servers now that this pat…
Resolving scalability issues is not as simple as "rent more servers".
For a CPU-bound problem it mostly is as simple as that, yes
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#26Earlier quoted context omitted.
Not entirely sure why we need to update/protect most servers, since generally they won't be running untrusted code, right?
In case there is a security hole in their Webserver (Apache, Nginx, HAProxy, etc) or their application (Wordpress, etc), that an attack cannot escalate privileges even further. Image someone manages to execute arbitrary PHP code, now they can gain gain root access, read private keys, etc. Things PHP should not have access to. For spectre, the consequences of not applying those patches are not as bad but it wouldn’t s…
Err, what? You can't get root access or escape a chroot from being able to read arbitrary memory.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#27Earlier quoted context omitted.
If they're operating on data supplied by the attacker, they're potentially a single hop away from executing untrusted code.
...at which point that untrusted code gains full access to the only userspace process that matters on that node. If you gain access to run code on a server process why escalate further, you already have access to everything that matters?... Assuming bare metal. In shared hosting / cloud / VMs it is different.
This is a great point. Probably someone will argue properly configured apache will not have access to data ... etc. I think the practical reality is in many setups it already does, and what these hardware bugs mean is that the lazy imperfect - effectively single layer - security that probably exists on the majority of servers is now essentially equivalent to the security of systems where the security minded have been incredibly diligent (and at considerable cost) ensuring multi layer security ... etc. So in some sense it is an attack on their value system and their worth/usefulness.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#28Earlier quoted context omitted.
Console manufacturers don't run unsigned code, so I expect they'll just sit still until the next hardware refresh.
Modern consoles now come with web browsers, and the researchers proved that the attacks could be performed via web browsers, did they not?
Next patch: we enhanced your security by disabling execution of JavaScript from untrusted domains. In unrelated news, we now block ads!
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#29Considering the performance impact, I wonder how console manufacturers are going to handle this (assuming that the processors they used are vulnerable to Spectre/Meltdown).
What console of the current generation comes with an Intel CPU? And in any case the Meltdown patch is not too bad for games.
> "What console of the current generation comes with an Intel CPU?"
The Switch appears to be based on ARM cores that are vulnerable.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#30Wow that's a huge jump. Scared for my web servers now
Not entirely sure why we need to update/protect most servers, since generally they won't be running untrusted code, right?
Belt and suspenders.
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.