6 ms·

The Meltdown attack requires an attacker to have a piece of code executed on your server. Epic's servers are used for login, where people send you data, and for

by Darthy 9y ago

The Meltdown attack requires an attacker to have a piece of code executed on your server. Epic's servers are used for login, where people send you data, and for game logic, where people also just send you data like "player x moved his avatar here, player y shoots etc". If all the server does is execute the code which Epic wrote themselves and already trust, why would it need to apply the Meltdown patch?

em3rgent0rdr 9y ago
Your argument also applied to other circumstances where the computer only runs trusted code. For example a fully FLOSS software stack on home computer with JavaScript disabled in the browser.
akira2501 9y ago
> why would it need to apply the Meltdown patch? They're using a "monolithic" cloud provider and don't have a choice in their current deployment?
drawnwren 9y ago
This is a horrible approach to security. If you only secure against attacks you expect, you're gonna have a bad time.
- deleted 9y ago
  [deleted]
- toomuchtodo 9y ago
  Security is about risk mitigation. You cannot derisk entirely, so you make tradeoffs. Without knowing all of the parameters, it’s disingenuous to say it’s a horrible approach to security. The most secure computer is powered off, enclosed in concrete 6 feet below the surface of the earth. It is not very useful though.
  - em3rgent0rdr 9y ago
    Reminds me of Battlestar Galactica. The humans were so (wisely) fearful of the Cylons that their ship computers were not networked in anyway. For their risk/reward trade-off curve, the benefit from having computer networks were not worth the risk of the Cylons being able to compromise the entire ship. All communication was either verbal or done via fax printed to paper and so had to go through human intermediaries.
    - toomuchtodo 9y ago
      Good catch!
  - userbinator 9y ago
    Very much this. In the real world, basically no one will make their house entirely bulletproof and never go outside just because of the possibility that someone could shoot them. Everyone knows that could happen, but is fine with the risk. "100% secure" is unattainable, and to attempt to achieve it to the exclusion of all other concerns is probably a very bad idea.
- merb 9y ago
  if you do not apply spectre/meltdown migtation on non virtualized hardware which only you control you are safe. of course a malicious process could do harm without them, but a malicious process probably can be as harmful, even if you have the patches applied. basically we need these patches since on the internet a ton of stuff lives on virtualized hardware and there you can actually be harmful to other vms or even the host itself. basically spectre/meltdown needs to be applied in hosted environments and on clients. on everything else it's way less scary than on those two environments.
  - msbarnett 9y ago
    Do you also run all processes on your server as root? If you’re not going to apply patches that close privilege escalation bugs, you might as well. You’re putting all your security eggs in one basket.
    - merb 9y ago
      Well a lot of processes run as Root anyway. Also if possible i run as few processes as possible
      - pixl97 9y ago
        >Well a lot of processes run as Root anyway. Then you didn't listen to DJB like 15 years ago. Moreso, your processes shouldn't be running under the same username. Principle of least user authorization people.
        merb 9y ago
        please just install a linux distribution and run ps aux. a ton of stuff just runs as root. either because there is no other way or because it's a bad default.
        msbarnett 9y ago
        Yeah it’s your job as a Unix dev or admin to not stick with crummy but convenient defaults, kid. Nothing exposed to the web or touching anything exposed to the web should be running as root. Each thing should be running under its own, very limited, user and group. If something gets hacked, you want it to be as least privileged as possible. We know how Unix works. We’re telling you because you clearly are out of your depth. If you don’t understand that you have no business maintaining anything on the internet.
- cookiecaper 9y ago
  Some things are just not applicable. There's no point adding another padlock to the outside wall of Fort Knox. If untrusted users don't send instructions to the same physical CPU that you're using, Meltdown/Spectre are not relevant. I also think that we need more information before we really see the long-term performance impact here. First, the patches will likely be optimized over time. Second, I am not sure that PTI needs to be run within guest kernels if the host already has the mitigation (effectively creating a double-hit from PTI in both the guest and host kernel), or that even if PTI is needed in both kernels now, that it will be needed long-term. We also need to figure out what type of Spectre mitigations need to be performed within the guest if the host system has the new microcode that selectively disables branch prediction. The short answer is that it's going to take another 4-6 weeks before even the kernel devs have a firm grasp of what's useful/necessary to mitigate this and for things to settle into place, as Greg K-H blogged about earlier. At that point, we should have a more realistic perspective on the long-term performance impact.
  - sigmar 9y ago
    >There's no point adding another padlock to the outside wall of Fort Knox. Strongly disagree. No single defense measure is infallible and defense in depth has proven one of the most important topics in computer security.
  - pixl97 9y ago
    In the past if you had a RCE that only got user level access and that user was very locked down there was only a limited amount of damage they could have done. Now with meltdown, every RCE is a full information loss at system level exploit.
- PascLeRasc 9y ago
  On the other hand, if you aren't affected by what a successful attacker can do, you're in a good place.
deleted 9y ago
[deleted]
progval 9y ago
It makes sense if you don't want a remote code execution in one of your app to provide a full root shell.
- omni 9y ago
  This is the correct, non-snarky answer. It's a known privilege escalation attack, turns a bad day (someone got a non-root account on my server) into a worse one (root account).
- Darthy 9y ago
  Thank you for the explanation, and especially for being non-snarky, which unfortunately seems to be getting rarer and rarer on this forum.
  - LV-426 9y ago
    > which unfortunately seems to be getting rarer and rarer on this forum. If this isn't unnecessarily "snarky" itself, then what is it? snarky: (of a person, words, or a mood) sharply critical; cutting; snide.
    - hungerstrike 9y ago
      That wasn't snarky because it was only mildly critical. Since it was mild, it also wasn't cutting. Lastly, it was not derogatory or mocking in an indirect way and so it was not snide either.
      - LV-426 9y ago
        I disagree. Aside from the sarcastic "buffer overflow" comment, his comment was far more snide than any of the replies he seemed to be complaining about. Since you take a different view though, as I asked in my post, if it's not "snarky" then what was it?
        trakout 9y ago
ardacinar 9y ago
> code executed on your server. Epic's servers are used for login, where people send you data, and for game logic, where people also just send you data like "player x moved his avatar here, player y shoots etc". Have you ever heard of the term 'buffer overflow'?
Pxtl 9y ago
I assume their servers will he running untrusted Unreal Engine games, maybe even community-developed mods, some of which may have attacks in the script of the game.
mrweasel 9y ago
Perhaps they don't, but eventually the patches become part of the mainline kernels, and then they will run with the patch applied. Regardless of what some of my customers believe patches are rarely hand picked and then applied. All security patches are applied, always, kernel patches even more so. They are rolled out with the tools provided by the operating system, be it Windows, Redhat, Ubuntu, OpenBSD, Solaris or whatever, and they don't make assumptions about your use case, they just apply all security patches.

by Darthy 9y ago

em3rgent0rdr 9y ago

Your argument also applied to other circumstances where the computer only runs trusted code. For example a fully FLOSS software stack on home computer with JavaScript disabled in the browser.

akira2501 9y ago

> why would it need to apply the Meltdown patch? They're using a "monolithic" cloud provider and don't have a choice in their current deployment?

drawnwren 9y ago

This is a horrible approach to security. If you only secure against attacks you expect, you're gonna have a bad time.

deleted 9y ago
[deleted]
toomuchtodo 9y ago
Security is about risk mitigation. You cannot derisk entirely, so you make tradeoffs. Without knowing all of the parameters, it’s disingenuous to say it’s a horrible approach to security. The most secure computer is powered off, enclosed in concrete 6 feet below the surface of the earth. It is not very useful though.
- em3rgent0rdr 9y ago
  Reminds me of Battlestar Galactica. The humans were so (wisely) fearful of the Cylons that their ship computers were not networked in anyway. For their risk/reward trade-off curve, the benefit from having computer networks were not worth the risk of the Cylons being able to compromise the entire ship. All communication was either verbal or done via fax printed to paper and so had to go through human intermediaries.
  - toomuchtodo 9y ago
    Good catch!
- userbinator 9y ago
  Very much this. In the real world, basically no one will make their house entirely bulletproof and never go outside just because of the possibility that someone could shoot them. Everyone knows that could happen, but is fine with the risk. "100% secure" is unattainable, and to attempt to achieve it to the exclusion of all other concerns is probably a very bad idea.
merb 9y ago
if you do not apply spectre/meltdown migtation on non virtualized hardware which only you control you are safe. of course a malicious process could do harm without them, but a malicious process probably can be as harmful, even if you have the patches applied. basically we need these patches since on the internet a ton of stuff lives on virtualized hardware and there you can actually be harmful to other vms or even the host itself. basically spectre/meltdown needs to be applied in hosted environments and on clients. on everything else it's way less scary than on those two environments.
- msbarnett 9y ago
  Do you also run all processes on your server as root? If you’re not going to apply patches that close privilege escalation bugs, you might as well. You’re putting all your security eggs in one basket.
  - merb 9y ago
    Well a lot of processes run as Root anyway. Also if possible i run as few processes as possible
    - pixl97 9y ago
      >Well a lot of processes run as Root anyway. Then you didn't listen to DJB like 15 years ago. Moreso, your processes shouldn't be running under the same username. Principle of least user authorization people.
      - merb 9y ago
        please just install a linux distribution and run ps aux. a ton of stuff just runs as root. either because there is no other way or because it's a bad default.
        msbarnett 9y ago
        Yeah it’s your job as a Unix dev or admin to not stick with crummy but convenient defaults, kid. Nothing exposed to the web or touching anything exposed to the web should be running as root. Each thing should be running under its own, very limited, user and group. If something gets hacked, you want it to be as least privileged as possible. We know how Unix works. We’re telling you because you clearly are out of your depth. If you don’t understand that you have no business maintaining anything on the internet.
cookiecaper 9y ago
Some things are just not applicable. There's no point adding another padlock to the outside wall of Fort Knox. If untrusted users don't send instructions to the same physical CPU that you're using, Meltdown/Spectre are not relevant. I also think that we need more information before we really see the long-term performance impact here. First, the patches will likely be optimized over time. Second, I am not sure that PTI needs to be run within guest kernels if the host already has the mitigation (effectively creating a double-hit from PTI in both the guest and host kernel), or that even if PTI is needed in both kernels now, that it will be needed long-term. We also need to figure out what type of Spectre mitigations need to be performed within the guest if the host system has the new microcode that selectively disables branch prediction. The short answer is that it's going to take another 4-6 weeks before even the kernel devs have a firm grasp of what's useful/necessary to mitigate this and for things to settle into place, as Greg K-H blogged about earlier. At that point, we should have a more realistic perspective on the long-term performance impact.
- sigmar 9y ago
  >There's no point adding another padlock to the outside wall of Fort Knox. Strongly disagree. No single defense measure is infallible and defense in depth has proven one of the most important topics in computer security.
- pixl97 9y ago
  In the past if you had a RCE that only got user level access and that user was very locked down there was only a limited amount of damage they could have done. Now with meltdown, every RCE is a full information loss at system level exploit.
PascLeRasc 9y ago
On the other hand, if you aren't affected by what a successful attacker can do, you're in a good place.

deleted 9y ago

[deleted]

progval 9y ago

It makes sense if you don't want a remote code execution in one of your app to provide a full root shell.

omni 9y ago
This is the correct, non-snarky answer. It's a known privilege escalation attack, turns a bad day (someone got a non-root account on my server) into a worse one (root account).
Darthy 9y ago
Thank you for the explanation, and especially for being non-snarky, which unfortunately seems to be getting rarer and rarer on this forum.
- LV-426 9y ago
  > which unfortunately seems to be getting rarer and rarer on this forum. If this isn't unnecessarily "snarky" itself, then what is it? snarky: (of a person, words, or a mood) sharply critical; cutting; snide.
  - hungerstrike 9y ago
    That wasn't snarky because it was only mildly critical. Since it was mild, it also wasn't cutting. Lastly, it was not derogatory or mocking in an indirect way and so it was not snide either.
    - LV-426 9y ago
      I disagree. Aside from the sarcastic "buffer overflow" comment, his comment was far more snide than any of the replies he seemed to be complaining about. Since you take a different view though, as I asked in my post, if it's not "snarky" then what was it?
      - trakout 9y ago

ardacinar 9y ago

> code executed on your server. Epic's servers are used for login, where people send you data, and for game logic, where people also just send you data like "player x moved his avatar here, player y shoots etc". Have you ever heard of the term 'buffer overflow'?

Pxtl 9y ago

I assume their servers will he running untrusted Unreal Engine games, maybe even community-developed mods, some of which may have attacks in the script of the game.

mrweasel 9y ago

Perhaps they don't, but eventually the patches become part of the mainline kernels, and then they will run with the patch applied. Regardless of what some of my customers believe patches are rarely hand picked and then applied. All security patches are applied, always, kernel patches even more so. They are rolled out with the tools provided by the operating system, be it Windows, Redhat, Ubuntu, OpenBSD, Solaris or whatever, and they don't make assumptions about your use case, they just apply all security patches.