5 ms·

An open question is still who should enable the mitigation. The risk-cost doesn't seem to fit too many scenarios. Meltdown requires running native, intrusted c

An open question is still who should enable the mitigation. The risk-cost doesn't seem to fit too many scenarios. Meltdown requires running native, intrusted code, and that doesn't apply to too many servers. While it may be possible to chain this onto another exploit, once an attacker has gained remote code execution, you have much bigger problems. While meltdown is interesting, i wouldn't enable kpti on my database servers buried behind other network infrastructure.

mehrdadn 9y ago
> Meltdown requires running native, intrusted code, and that doesn't apply to too many servers. While it may be possible to chain this onto another exploit, once an attacker has gained remote code execution, you have much bigger problems. https://react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript https://react-etc.net/entry/exploiting-speculative-execution...
- prewett 9y ago
  You realize he's talking about his servers, and the article is talking about Javascript running in the browser, right? The only things talking to his database server is his own server code via SQL queries; if there's any browsers and third-party Javascript running on that database server he's had a real security meltdown, of the kind that makes Meltdown irrelevant.
  - mehrdadn 9y ago
    Yes? I'm just addressing his assertion that "Meltdown requires running native, intrusted code".
    - cookiecaper 9y ago
      He's not wrong, it's just that your browser does that automatically every time it loads a web page. That's an insecure-by-default security model and it's why people run JavaScript blockers like NoScript. A server, however, is unlikely to do this, so the risk profile of something like Meltdown is much lower. It's not nil because if someone does get on your box, whether they're supposed to be there or not, Meltdown can be leveraged to read the memory anywhere on the system, effectively neutering the protections of a multi-user operating system. This is a major information risk by itself since it could leak important things like encryption keys or user login info, but it could also be used to make local privilege escalation exploits simpler. (That said, if a remote user is able to get a shell on your box and submit code to the CPU, it's probably not likely that you won't already have a latent local escalation vulnerability that can be chained to get root.) So he's right that people who don't execute arbitrary code on their CPU are much less vulnerable, but they're not totally invulnerable because you can't really guarantee that no one will be able to submit instructions to your CPU due to RCEs and the like. Also, you essentially need to trust everyone who has shell access to your server with anything that may be held in the server's memory, including keys, passwords, etc. People who are considering disabling KPTI will have to decide whether they want to make the extra local attack surface available in exchange for the performance gain under normal operation.
- jnordwick 9y ago
  There is no Meltdown JavaScript exploit that i know of. This page lumps them together. To exploit meltdown you need to peek at specific places of memory (and flush the probe array from cache which might not be possible in JS easily).
  - roblabla 9y ago
    Your knowledge is broken then. There's literally an example in the Spectre Whitepaper. Here is the example from the whitepaper: https://react-etc.net/page/meltdown-spectre-javascript-exploit-example https://react-etc.net/page/meltdown-spectre-javascript-explo...
    - deleted 9y ago
      [deleted]
    - jnordwick 9y ago
      How does that apply to the Meltdown and these KPTI-related slowdowns? Can you be a little more specific about this JavaScript meltdown implementation in the Spectre paper?

mehrdadn 9y ago

> Meltdown requires running native, intrusted code, and that doesn't apply to too many servers. While it may be possible to chain this onto another exploit, once an attacker has gained remote code execution, you have much bigger problems. https://react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript https://react-etc.net/entry/exploiting-speculative-execution...

prewett 9y ago
You realize he's talking about his servers, and the article is talking about Javascript running in the browser, right? The only things talking to his database server is his own server code via SQL queries; if there's any browsers and third-party Javascript running on that database server he's had a real security meltdown, of the kind that makes Meltdown irrelevant.
- mehrdadn 9y ago
  Yes? I'm just addressing his assertion that "Meltdown requires running native, intrusted code".
  - cookiecaper 9y ago
    He's not wrong, it's just that your browser does that automatically every time it loads a web page. That's an insecure-by-default security model and it's why people run JavaScript blockers like NoScript. A server, however, is unlikely to do this, so the risk profile of something like Meltdown is much lower. It's not nil because if someone does get on your box, whether they're supposed to be there or not, Meltdown can be leveraged to read the memory anywhere on the system, effectively neutering the protections of a multi-user operating system. This is a major information risk by itself since it could leak important things like encryption keys or user login info, but it could also be used to make local privilege escalation exploits simpler. (That said, if a remote user is able to get a shell on your box and submit code to the CPU, it's probably not likely that you won't already have a latent local escalation vulnerability that can be chained to get root.) So he's right that people who don't execute arbitrary code on their CPU are much less vulnerable, but they're not totally invulnerable because you can't really guarantee that no one will be able to submit instructions to your CPU due to RCEs and the like. Also, you essentially need to trust everyone who has shell access to your server with anything that may be held in the server's memory, including keys, passwords, etc. People who are considering disabling KPTI will have to decide whether they want to make the extra local attack surface available in exchange for the performance gain under normal operation.
jnordwick 9y ago
There is no Meltdown JavaScript exploit that i know of. This page lumps them together. To exploit meltdown you need to peek at specific places of memory (and flush the probe array from cache which might not be possible in JS easily).
- roblabla 9y ago
  Your knowledge is broken then. There's literally an example in the Spectre Whitepaper. Here is the example from the whitepaper: https://react-etc.net/page/meltdown-spectre-javascript-exploit-example https://react-etc.net/page/meltdown-spectre-javascript-explo...
  - deleted 9y ago
    [deleted]
  - jnordwick 9y ago
    How does that apply to the Meltdown and these KPTI-related slowdowns? Can you be a little more specific about this JavaScript meltdown implementation in the Spectre paper?