6 ms·

Wow that's a huge jump. Scared for my web servers now

lsd5you 9y ago
Not entirely sure why we need to update/protect most servers, since generally they won't be running untrusted code, right?
- ZenoArrow 9y ago
  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.
  - lsd5you 9y ago
    Ok, sure, but we have to consider whether that is worth it, and if they can run unpriveleged code, there is a good chance there is a software privelege escalation available anyway. Of course on shared servers this is going to be a nightmare.
  - randyrand 9y ago
    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 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.
    - ZenoArrow 9y ago
      > "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.
- s_kilk 9y ago
  If they're operating on data supplied by the attacker, they're potentially a single hop away from executing untrusted code.
  - dagss 9y ago
    ...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.
    - chrisper 9y ago
      With Meltdown / Spectre you can break out of sandboxes as far as I understand.
      - yorwba 9y ago
        That only matters if not everything is in the same sandbox. Many non-cloud servers probably either only run a single service, or they run all processes as the same user, which means that a sandbox escape doesn't really matter. You can't lose any security layers you never had in the first place.
    - lsd5you 9y ago
      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.
      - jameshart 9y ago
- Matt3o12_ 9y ago
  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 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.
  - angelsl 9y ago
    Err, what? You can't get root access or escape a chroot from being able to read arbitrary memory.
    - Matt3o12_ 9y ago
      Yes you can? If password login is enabled, you could wait until someone SSHs in and read their decrypted password. You could read all kinds of secrets which will be very useful for gaining privileged information. Sure you can’t just become root but it is one way to get there. 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.
    - baq 9y ago
      You don't need anything special to escape a chroot, it's never been intended as a security feature.
    - ZenoArrow 9y ago
      If you can dump the memory holding security certificates, I'd suggest you probably can. 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.
- InclinedPlane 9y ago
  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.
- rocqua 9y ago
  The replies are missing something from the original article. 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.
  - Asdfbla 9y ago
    I suppose if a Cloud provider could ensure that all your VM instances run on the same host and no other VM is allowed there then the issue would be a bit mitigated. 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)?
    - asheldon 9y ago
      AWS provides the ability to guarantee you don't share physical hardware with other customers with "EC2 Dedicated Instances" (https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/ https://aws.amazon.com/ec2/purchasing-options/dedicated-inst...). I'm not familiar enough with other cloud provider offerings to say if they do or do not have similar features.
    - Fargren 9y ago
      With AWS, and I assume most other cloud computing providers, you can pay extra for you instances to run in a host without someone else's VMs. You probably should be doing this for any servers were you handle sensitive data, but it is a place were many will be cutting corners.
      - mrep 9y ago
        You don't really even have to pay extra. Just use the biggest instance since and you are guaranteed to be isolated because there is no room for anyone else. Granted, that only works for workloads that are spread across enough small instances.
  - 9y ago

Not entirely sure why we need to update/protect most servers, since generally they won't be running untrusted code, right?

ZenoArrow 9y ago
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.
- lsd5you 9y ago
  Ok, sure, but we have to consider whether that is worth it, and if they can run unpriveleged code, there is a good chance there is a software privelege escalation available anyway. Of course on shared servers this is going to be a nightmare.
- randyrand 9y ago
  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 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.
  - ZenoArrow 9y ago
    > "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.
s_kilk 9y ago
If they're operating on data supplied by the attacker, they're potentially a single hop away from executing untrusted code.
- dagss 9y ago
  ...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.
  - chrisper 9y ago
    With Meltdown / Spectre you can break out of sandboxes as far as I understand.
    - yorwba 9y ago
      That only matters if not everything is in the same sandbox. Many non-cloud servers probably either only run a single service, or they run all processes as the same user, which means that a sandbox escape doesn't really matter. You can't lose any security layers you never had in the first place.
  - lsd5you 9y ago
    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.
    - jameshart 9y ago
Matt3o12_ 9y ago
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 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.
- angelsl 9y ago
  Err, what? You can't get root access or escape a chroot from being able to read arbitrary memory.
  - Matt3o12_ 9y ago
    Yes you can? If password login is enabled, you could wait until someone SSHs in and read their decrypted password. You could read all kinds of secrets which will be very useful for gaining privileged information. Sure you can’t just become root but it is one way to get there. 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.
  - baq 9y ago
    You don't need anything special to escape a chroot, it's never been intended as a security feature.
  - ZenoArrow 9y ago
    If you can dump the memory holding security certificates, I'd suggest you probably can. 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.
InclinedPlane 9y ago
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.
rocqua 9y ago
The replies are missing something from the original article. 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.
- Asdfbla 9y ago
  I suppose if a Cloud provider could ensure that all your VM instances run on the same host and no other VM is allowed there then the issue would be a bit mitigated. 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)?
  - asheldon 9y ago
    AWS provides the ability to guarantee you don't share physical hardware with other customers with "EC2 Dedicated Instances" (https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/ https://aws.amazon.com/ec2/purchasing-options/dedicated-inst...). I'm not familiar enough with other cloud provider offerings to say if they do or do not have similar features.
  - Fargren 9y ago
    With AWS, and I assume most other cloud computing providers, you can pay extra for you instances to run in a host without someone else's VMs. You probably should be doing this for any servers were you handle sensitive data, but it is a place were many will be cutting corners.
    - mrep 9y ago
      You don't really even have to pay extra. Just use the biggest instance since and you are guaranteed to be isolated because there is no room for anyone else. Granted, that only works for workloads that are spread across enough small instances.
- 9y ago