6 ms·
Which is perfectly fine for personal use or in a data center where you control the whole server.
by bufferoverflow 6y ago
Which is perfectly fine for personal use or in a data center where you control the whole server.
- sneak 6y agoPersonal use usually involves a web browser, which usually executes untrusted javascript from the web. You won't find me disabling these mitigations on any of my workstations any time soon.
- mahkoh 6y agoIs there a poc of an attack that works on an up-to-date browser iff these mitigations are disabled?
- RIMR 6y agoYes, the original Javascript exploit from the paper still works, because the browser cannot mitigate this attack without just disabling parts of Javascript entirely which breaks Javascript. With all current kernels built to mitigate these exploits, and all sane people running those kernels, there's no benefit in patching the browsers too, even if it were somehow possible, which for all intents and purposes it is not. https://react-etc.net/page/meltdown-spectre-javascript-exploit-example https://react-etc.net/page/meltdown-spectre-javascript-explo...
- gowld 6y agoCan you or someone explain that exploit? Where is it reading out of bounds data?
- bawolff 6y agoI'm not super familar with spectre, but i think the linked page is misinterpreting the vuln (hopefully someone will correct me if im totally out to lunch). So the original js from the spectre paper was: if (index < simpleByteArray.length) { index = simpleByteArray[index | 0]; index = (((index * 4096)|0) & (32*1024*1024-1))|0; localJunk ˆ= probeTable[index|0]|0; } The code looking a bit weird (all the |0) to ensure Chrome JITs it the correct way. My understanding of what happens, the loop goes a bunch of times while index is inside the simple byte array. After the last iteration, the processor speculatively executes the loop one more time than it should (branch misprediction). It eventually figures out the loop should end and undos the speculative execution. However that only happens after the loop has already started executing (where its not supposed to). During this improper execution, index is after the end of SimpleByteArray. index = simpleByteArray[index | 0] is then executed. index is now set to the value of some memory in the current process that the current JS is not supposed to access. index = (((index * 4096)|0) & (3210241024-1))|0; is executed to spread the memory value out (we need all possible values to be in a separate cache line in probeTable later). We now execute localJunk ˆ= probeTable[index|0]|0;. localJunk is just there to prevent dead code elimination optimization. Since we are now indexing into probeTable at 4096 byte intervals, we have to fetch that value from memory. It then gets cached by processor. This all gets undone by the processor when it realizes that the branch was incorrect, except the cache changes are not undone. If we access anything else in the same 4096 bytes later on, the access is a tiny bit quicker. The exploit is, that after all that setup, we try accessing each 4096 byte region of probeTable, to see which one is fastest. We can than conclude that was the value of index during the branch misprediction and thus the value of that byte of memory we aren't supposed to see. If we do this a lot, we can read the rest of the process's memory. The hope is we will be able to find cookies related to other websites currently open, and then do evil things with them. This attack no longer works because browsers disabled SharedArrayBuffer, which provided the really precise timer. The timing difference is very small so you need a very fine grained timer to make it work. It should also be noted that this variant of spectre is in-process only. Some versions of meltdown/spectre allow accessing memory of other processes, but as far as i understand this version is in process only. I hope that made sense, and i hope i didnt screw that up.
- gowld 6y agoThank you! > to see which one is fastest. The timing is extremely important and not at all visible in the code (which makes sense, since it's a side-channel attack.)
- mahkoh 6y agoYou've linked an "example" but what I'm looking for is a complete poc that I can execute to see for myself that it works.
- icedchai 6y agoYou won't find a real world exploit that does something like reading a password, SSH key, etc. It would be like winning the lottery, then getting your money out 1 penny at a time for the next several decades. You can find "academic" PoC exploits that work under pristine conditions.
- saagarjha 6y agoI don't see how that code exploits anything?
- bawolff 6y agoNote, browsers did disable some js features to mitigate - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Well the link you provide doesnt use SharedArrayBuffer, it is used as part of the exploit if you read the original paper (as a method to make a high resolution timer)
- umvi 6y agoIn my mind javascript is so many layers removed from machine code that it would be insanely hard to even break out of the chrome sandbox let alone glean anything useful from other running processes. Practically speaking, what is possible?
- noiv 6y agoYou might want to google: 'javascript spectre exploit'.
- animalCrax0rz 6y agoThat depends on high resolution times which have been disabled in all browsers. AFAIK.
- saagarjha 6y agoThere are variants of Spectre that do not require a high resolution timer. Here's some thoughts on working around browser mitigations: https://alephsecurity.com/2018/06/26/spectre-browser-query-cache/ https://alephsecurity.com/2018/06/26/spectre-browser-query-c...
- animalCrax0rz 6y ago"We were not able use these techniques in Firefox, as they recently reduced the timer resolution to 2ms. The techinque presented here is potentially relevant even for this timer resolution, but some parameter tweaking is required.?" AFAIK, Chrome's highest resolution is also in the ms range. I have some thoughts, too, but thoughts don't amount to a working exploit. Show me a currently working exploit, that is in the open. As far as state actors developing such exploits, there are a ton of holes in that scenario at every layer in the stack.
- saagarjha 6y agoTheir PoC focused on Chrome. I would assume that "parameter tweaking" probably means "change some things to make it work but run slower".
- bufferoverflow 6y agoShow us a shred of evidence attacks via javascript are viable using these vulnerabilities. I run ScriptBlock anyway, so it's even less of a concern for me.
- deleted 6y ago[deleted]
- cipherboy 6y agohttps://github.com/ascendr/spectre-chrome https://github.com/ascendr/spectre-chrome https://github.com/cgvwzq/spectre https://github.com/cgvwzq/spectre https://github.com/alephsecurity/spectreBrowserResearch https://github.com/alephsecurity/spectreBrowserResearch https://react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript https://react-etc.net/entry/exploiting-speculative-execution... https://www.tomshardware.com/news/meltdown-spectre-exploit-browser-javascript,36221.html https://www.tomshardware.com/news/meltdown-spectre-exploit-b... (I haven't found a JS PoC for Meltdown but I didn't look long.)
- deleted 6y ago[deleted]
- bufferoverflow 6y agoI opened the first link. The description starts with. Enable `#shared-array-buffer` in `chrome:///flags` under your own risk...
- danShumway 6y agoShared Array Buffers are enabled by default in Chrome now, because Chrome has separate mitigations against Spectre. To the best of my knowledge, it does not have mitigations against Meltdown because it assumes those protections will be implemented at the OS/firmware level, but if anyone has more experience or insight than me on that front, they're welcome to correct me. In any case, you're making a kind of wild assumption that the type of user who disables a security feature from their OS to get a speed increase won't also likely disable security features like Site Isolation in their browser when they hear that those features increase Chrome's memory usage by somewhere between 10-20%.
- AnIdiotOnTheNet 6y agoEh. The amount of performance you sacrifice in order to mitigate the very small chance of actually running across any javascript in the wild that a) successfully exploits you, and b) actually retrieves anything worthwhile, just isn't worth it. It's such a tiny risk that it's really only worth mitigating against if you're paranoid or handling particularly sensitive information.
- animalCrax0rz 6y agoAgain, JS can no longer perform this exploit. Browser vendors have disabled (made inoperable) high resolution timing. It's now at 1ms resolution. Not enough timing resolution to mount the attack.
- admax88q 6y agoWasn't there a POC of spectre that used a counter in a webworker as a timer?
- animalCrax0rz 6y agopostMessage cannot provide a reliable timing signal since it goes on the task queue on the receiving end (in the main thread) along with other pending events, and even if there were no other events, there is latency noise in postMessage due to the fact that the web worker is not the only thread running on the CPU. Some suggest that the attack would only take more time as the attacker has to collect a bigger sample, and factor out the noise, but I haven't seen a public exploit based on that. The other angle of attack that used to be viable was documented in this HN comment: https://news.ycombinator.com/item?id=14057091 https://news.ycombinator.com/item?id=14057091 But AFAIK all browsers have disabled SAB, e.g. see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... EDIT: Chrome has re-enabled SAB, with mitigations.
- 6510 6y agoAh, bloat as a security feature. I keep learning new things here!