3 ms·

>The browser mitigation’s only work with the kernel mitigation’s. That's just not true. The timer precision doesn't have anything to do with the kernel mitigat

>The browser mitigation’s only work with the kernel mitigation’s. That's just not true. The timer precision doesn't have anything to do with the kernel mitigations.

dijit 7y ago
The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time. The browser vendors themselves said this; and it's not a permanent solution as tech such as Stadia and WebVR rely on high precision timers. But, whatever man, I'm telling you that it's stupid and you want to bury your head in the sand. You just make these attacks more likely; I'm not going to be impacted except for a few trillion CPU cycles of idiots trying to exploit me. You're the one who puts their entire digital life on the line by eking out 5% performance.
- scandinavian 7y ago
  >The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time. Oh, so it just takes more time, so you have knowledge of an exploit? Fine, show me any PoC or similar bypassing the lower accuracy and site isolation. You are such a big part of the problem with how this whole class of exploits have been handled. No technical knowledge, just spewing stuff like "You're the one who puts their entire digital life on the line", when we there is no indication that anything like that can transpire. Please stop spreading misinformation.
  - dijit 7y ago
    Except that the Spectre paper already takes degraded timers into account and suggests to use a Web Worker thread that increments a value in a loop as a replacement. This is not misinformation, _you_ are spreading "certainty" of safety surrounding a dangerous idea. https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up.
    - scandinavian 7y ago
      >Except that the Spectre paper already takes degraded timers into account and suggests to use a Web Worker thread that increments a value in a loop as a replacement. Yeah, which was why SharedArrayBuffer was disabled when spectrev1 was released. It is still disabled in Chrome if site-isolation is disabled and it's still disabled in firefox. You should really know all this if you are so very well versed in the subject. >Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up. I don't run without migrations. I commented on the original parent comments threat model and that I think it's perfectly logical. And I maintain this, if your threat model is so strict, that you are afraid of speculative execution vulnerabilities hitting you through javascript, you should not run JS at all, as regular js 0days have hit while no actual speculative execution browser exploits have hit.
      - dijit 7y ago
        “Threat model is so strict” is weird to say when any ad network can access any and all memory on your desktop potentially. That’s a very wide attack scope.
        scandinavian 7y ago
        You have misunderstood how the browser attacks work. They are limited to the memory assigned to the browser process. If site-isolation and the other browser mitigations were somehow bypassed, an ad-network would potentially be able to read some data from other loaded tabs. You can't use the speculative execution vulnerabilities to just read all system memory using a javascript exploit. Like the exploit that is the topic of this post can't be used in a browser at all, as you are limited to what the JIT executes, you can't just execute TSX instructions in a browser. You might be thinking of when you have native code execution.
        saurik 7y ago
        The website covers a handful of things, and the RIDL exploits don't require special instructions. > We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine.
  - dang 7y ago
    Personal attacks are not ok on HN and we ban accounts that do that, so please don't do that—regardless of how wrong another comment is or you feel it is. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

>The browser mitigation’s only work with the kernel mitigation’s. That's just not true. The timer precision doesn't have anything to do with the kernel mitigations.

dijit 7y ago

The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time. The browser vendors themselves said this; and it's not a permanent solution as tech such as Stadia and WebVR rely on high precision timers. But, whatever man, I'm telling you that it's stupid and you want to bury your head in the sand. You just make these attacks more likely; I'm not going to be impacted except for a few trillion CPU cycles of idiots trying to exploit me. You're the one who puts their entire digital life on the line by eking out 5% performance.

scandinavian 7y ago
>The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time. Oh, so it just takes more time, so you have knowledge of an exploit? Fine, show me any PoC or similar bypassing the lower accuracy and site isolation. You are such a big part of the problem with how this whole class of exploits have been handled. No technical knowledge, just spewing stuff like "You're the one who puts their entire digital life on the line", when we there is no indication that anything like that can transpire. Please stop spreading misinformation.
- dijit 7y ago
  Except that the Spectre paper already takes degraded timers into account and suggests to use a Web Worker thread that increments a value in a loop as a replacement. This is not misinformation, _you_ are spreading "certainty" of safety surrounding a dangerous idea. https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up.
  - scandinavian 7y ago
    >Except that the Spectre paper already takes degraded timers into account and suggests to use a Web Worker thread that increments a value in a loop as a replacement. Yeah, which was why SharedArrayBuffer was disabled when spectrev1 was released. It is still disabled in Chrome if site-isolation is disabled and it's still disabled in firefox. You should really know all this if you are so very well versed in the subject. >Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up. I don't run without migrations. I commented on the original parent comments threat model and that I think it's perfectly logical. And I maintain this, if your threat model is so strict, that you are afraid of speculative execution vulnerabilities hitting you through javascript, you should not run JS at all, as regular js 0days have hit while no actual speculative execution browser exploits have hit.
    - dijit 7y ago
      “Threat model is so strict” is weird to say when any ad network can access any and all memory on your desktop potentially. That’s a very wide attack scope.
      - scandinavian 7y ago
        You have misunderstood how the browser attacks work. They are limited to the memory assigned to the browser process. If site-isolation and the other browser mitigations were somehow bypassed, an ad-network would potentially be able to read some data from other loaded tabs. You can't use the speculative execution vulnerabilities to just read all system memory using a javascript exploit. Like the exploit that is the topic of this post can't be used in a browser at all, as you are limited to what the JIT executes, you can't just execute TSX instructions in a browser. You might be thinking of when you have native code execution.
        saurik 7y ago
        The website covers a handful of things, and the RIDL exploits don't require special instructions. > We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine.
- dang 7y ago
  Personal attacks are not ok on HN and we ban accounts that do that, so please don't do that—regardless of how wrong another comment is or you feel it is. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html