4 ms·

> Spectre Spectre doesn't really care if it is cloud or bare metal. They are equally vulnerable unless disconnected from internet.

Godel_unicode 9y ago
Pretty hard to have a neighbor vm execute Spectre on your same physical server if you have dedicated hardware. Add in that Spectre specifically is a js bug so in order to be vulnerable your server would need to execute untrusted JavaScript and I think we can assume the threat surface of this specific bug is smaller outside the cloud...
- cthalupa 9y ago
  I don't think you understand the bug here. 1) https://spectreattack.com/ https://spectreattack.com/: "Spectre tricks other applications into accessing arbitrary locations in their memory. " Spectre does not let you execute code in another guest 2) Spectre is not javascript specific. I am not sure why you think it is, beyond the fact a PoC was written in js
  - Godel_unicode 9y ago
    I don't think you understand my point. You should reread my post, especially the first sentence. It's first and alone for a reason; not sharing hardware is an effective mitigation against vulnerabilities in shared hardware. Obviously it's not just a js bug, there are other PoCs in other languages. I never said anything about executing code in another guest, not sure where you got that from.
    - TickleSteve 9y ago
      Spectre is exploitable from processes, not just containers.... containers are equivalent to processes from it's point-of-view as the kernel is shared. So... you may be able to go native to avoid having neighbours, but this does not prevent other processes exploiting your process. To do that you need to prevent any downloadable code from running. This of course is possible and is the entire reason why the ARM document explains that most embedded systems are not affected due to the fact that they will not download and execute code (of any form).
    - cthalupa 9y ago
      >Pretty hard to have a neighbor vm execute Spectre on your same physical server if you have dedicated hardware. You have no reason to care about a neighbor VM executing Spectre on the same physical server, since they're only hurting themselves, not you. >Add in that Spectre specifically is a js bug so in order to be vulnerable your server would need to execute untrusted JavaScript and I think we can assume the threat surface of this specific bug is smaller outside the cloud... "Spectre specifically is a js bug"
- spotman 9y ago
  Pretty sure that its not limited to js: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6 https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9... Its a technique, not a flaw in js, from my understanding
  - Godel_unicode 9y ago
    This PoC is implemented in js, but my point stands regardless of the language used. It requires code executing on the same physical server as your app in order to be an issue for you. Similar to a hypervisor escape (since we're being pedantic yes, I understand this is not a hypervisor escape), the evil neighbor surface is not present if you have no neighbors.
snowwrestler 9y ago
To get you with Spectre, the attacker must be able to run code on your CPU. This affects browsers with Javascript enabled because your Javascript engine runs foreign code on the CPU. The bad guy puts nasty code in a page, you visit the page, the code executes on your machine--boom. And it affects public cloud web servers because multiple cloud servers (virtual machines) run on one CPU. So some attacker might be able to jump out of their VM and read your VM's memory. BUT, on a dedicated hardware web server, there shouldn't be any foreign code running--no foreign VMs, and no browser.
- user5994461 9y ago
  There are many dedicated servers that are shared across users or clients and were expected to be isolated. Any user who has access to a system (developers or support or sysadmin) has the ability to read arbitrary memory. The vulnerability can probably be leveraged to privilege escalation or bypass the isolation.
- tanilama 9y ago
  Spectre doesn't let u do cross VM memory reading, Meltdown does, AFAIK. If you want to read other VMs memory, u need to RUN in those VMs yourself and within the right process. So cloud instance and bare metal ones are equally vulnerable under Spectre: as long as they can transfer their malicious code to your VMs and runs it. Can't really see how bare metal servers mitigate this problem.

Godel_unicode 9y ago

Pretty hard to have a neighbor vm execute Spectre on your same physical server if you have dedicated hardware. Add in that Spectre specifically is a js bug so in order to be vulnerable your server would need to execute untrusted JavaScript and I think we can assume the threat surface of this specific bug is smaller outside the cloud...

cthalupa 9y ago
I don't think you understand the bug here. 1) https://spectreattack.com/ https://spectreattack.com/: "Spectre tricks other applications into accessing arbitrary locations in their memory. " Spectre does not let you execute code in another guest 2) Spectre is not javascript specific. I am not sure why you think it is, beyond the fact a PoC was written in js
- Godel_unicode 9y ago
  I don't think you understand my point. You should reread my post, especially the first sentence. It's first and alone for a reason; not sharing hardware is an effective mitigation against vulnerabilities in shared hardware. Obviously it's not just a js bug, there are other PoCs in other languages. I never said anything about executing code in another guest, not sure where you got that from.
  - TickleSteve 9y ago
    Spectre is exploitable from processes, not just containers.... containers are equivalent to processes from it's point-of-view as the kernel is shared. So... you may be able to go native to avoid having neighbours, but this does not prevent other processes exploiting your process. To do that you need to prevent any downloadable code from running. This of course is possible and is the entire reason why the ARM document explains that most embedded systems are not affected due to the fact that they will not download and execute code (of any form).
  - cthalupa 9y ago
    >Pretty hard to have a neighbor vm execute Spectre on your same physical server if you have dedicated hardware. You have no reason to care about a neighbor VM executing Spectre on the same physical server, since they're only hurting themselves, not you. >Add in that Spectre specifically is a js bug so in order to be vulnerable your server would need to execute untrusted JavaScript and I think we can assume the threat surface of this specific bug is smaller outside the cloud... "Spectre specifically is a js bug"
spotman 9y ago
Pretty sure that its not limited to js: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6 https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9... Its a technique, not a flaw in js, from my understanding
- Godel_unicode 9y ago
  This PoC is implemented in js, but my point stands regardless of the language used. It requires code executing on the same physical server as your app in order to be an issue for you. Similar to a hypervisor escape (since we're being pedantic yes, I understand this is not a hypervisor escape), the evil neighbor surface is not present if you have no neighbors.

snowwrestler 9y ago

To get you with Spectre, the attacker must be able to run code on your CPU. This affects browsers with Javascript enabled because your Javascript engine runs foreign code on the CPU. The bad guy puts nasty code in a page, you visit the page, the code executes on your machine--boom. And it affects public cloud web servers because multiple cloud servers (virtual machines) run on one CPU. So some attacker might be able to jump out of their VM and read your VM's memory. BUT, on a dedicated hardware web server, there shouldn't be any foreign code running--no foreign VMs, and no browser.

user5994461 9y ago
There are many dedicated servers that are shared across users or clients and were expected to be isolated. Any user who has access to a system (developers or support or sysadmin) has the ability to read arbitrary memory. The vulnerability can probably be leveraged to privilege escalation or bypass the isolation.
tanilama 9y ago
Spectre doesn't let u do cross VM memory reading, Meltdown does, AFAIK. If you want to read other VMs memory, u need to RUN in those VMs yourself and within the right process. So cloud instance and bare metal ones are equally vulnerable under Spectre: as long as they can transfer their malicious code to your VMs and runs it. Can't really see how bare metal servers mitigate this problem.