4 ms·
"Don't mind me running this piece of WASM in a webworker to collect all the useful encryption keys and cookies in your RAM..."
by matja 1y ago
"Don't mind me running this piece of WASM in a webworker to collect all the useful encryption keys and cookies in your RAM..."
- johnnyjeans 1y agoUncaught ReferenceError: WebAssembly is not defined
- vlovich123 1y agoYou don't need WASM to deploy Spectre/Meltdown. Vanilla JS works just fine which is what was demonstrated in the original paper.
- deleted 1y ago[deleted]
- brobinson 1y agoDidn't all the major browsers alter their timing APIs to make this impossible/difficult?
- anyfoo 1y agoI'm not an expert, but I think you can only make this harder by intentionally making timers less precise (even adding some random fuzz). Someone may correct me if I'm wrong, but I think statistically, a less precise timer means you will just need a longer runtime. Suppose you want to measure the distribution of the delay between recurring events (which is basically what's at the heart of those vulnerabilities). Suppose the delays are all sub-milliseconds, and that your timer, to pick something ridiculous, only has a 2 second granularity. You may at first think that you cannot measure the sub-millisecond distribution with such a corse timer. But consider that event and timers are not synchronized to each other, so with enough patience, you will still catch some events barely on the left or on the right side of your 2 second timer tick. Do this over a long enough time, and you can reconstruct the original distribution. Even adding some randomness to the timer tick just means you need more samples to suss the statistic out. Again, I am not an expert, and I don't know if this actually works, but that's what I came up with intuitively, and it matches with what I heard from some trustworthy people on the subject, namely that non-precision timers are not a panacea.
- teruakohatu 1y ago> Even adding some randomness to the timer tick just means you need more samples to suss the statistic out. If each timer draws from the same random distribution then sure, you could work out the real tick with greater accuracy, but I don’t know if that is practical. If the timers draw from different distributions then it is going to be much harder. I imagine there is an upper limit of how much processing can be done per tick to before any attack becomes implausible.
- anyfoo 1y ago> If the timers draw from different distributions then it is going to be much harder. Again, I'm an amateur, but I think you just need to know that distribution, which I guess you usually do (open source vs. closed source barely matters there), law of large numbers and all. Anyway, looking through literature, this article presents some actual ways to circumvent timers being made corse-grained: https://attacking.systems/web/files/timers.pdf https://attacking.systems/web/files/timers.pdf In that article, the "Clock interpolation" sounds vaguely related to what I was describing on a quick read, or maybe it's something else entirely... Later, the article mentions alternative timing sources altogether. Either way, the conclusion of the article is that the mitigation approach as a whole is indeed ineffective: "[...] browser vendors decided to reduce the timer resolution. In this article, we showed that this attempt to close these vulnerabilities was merely a quick-fix and did not address the underlying issue. [...]"
- vlovich123 1y agoI believe your understanding of the literature is correct (I too am an amateur when it comes to side channel attacks). My memory is vague here but I believe that while it still lets you exploit side channels, it still requires extra time to do so which lowers the throughput you get out of the gadget.
- vlovich123 1y agoThey are not a panacea (in some cases - the way Cloudflare Workers does them it does more effectively limit attacks vs how browsers have to work) but slowing down an attack is valuable because it can make the attack infeasible because your ability to retrieve anything damaging is bounded by how long you visit that website.
- vlovich123 1y agoThey temporarily disabled high resolution timing APIs until they rearchitected how JS got executed in the wake of spectre/meltdown. They sandboxed JS into separate processes by domain (site-isolation) & created the concept of cross-origin isolation. The combination of the two lets you gain back sub-millisecond timers and SharedArrayBuffer which are two gadgets that were particularly useful for the Spectre paper.
- bee_rider 1y agoYeah, he should really turn mitigations on, so that when running arbitrary code from the internet he can be subject to 9999 vulnerabilities, instead of 10,000.
- darkmighty 1y agoThere are many kinds of vulnerabilities. Most are pretty mundane afaict. Breaking sandboxes and reading out your entire RAM is basically game over, existential vulnerability (second only to arbitrary code execution, though it can give you SSH keys I guess). The mitigating factor is actually that you don't go to malicious websites all the time, hopefully. But it happens, including with injected code on ads and stuff that may enabled by secondary vulnerabilities.
- anyfoo 1y agoI challenge you to name another readily available "read arbitrary RAM from userspace"[1] vulnerability. [1] Not even including "potentially exploitable from JavaScript", which Spectre was. It's sufficient if you name one where an ordinary userspace program can do it.
- genewitch 1y agoCan't you trivially do this with 4 lines of C?
- Akronymus 1y agoOnly if you already have the ability to read arbitrary RAM. So running in kernel/hypervisor mode. The exploit is being able to do it from usermode through an api (browser/js) that normally forbids that. Userspace can only access its own memory, rather than the whole systems.
- anyfoo 1y agoUserspace processes can only read their own memory, or what has been shared with them.
- 201984 1y agoHas even a single web exploit ever been found in the wild? Until then, I'm not going to worry and probably not even then.
- dzaima 1y agoAs long as most people run with mitigations on, you're technically probably indeed safe. But you should still care that things get fixed with mitigations=on otherwise you wouldn't have the shield of "almost everyone has mitigations enabled for this so noone has reason to bother exploiting this"!
- autoexec 1y agoYes, at least in the Spectre/Meltdown days. https://www.techtarget.com/searchsecurity/news/252434342/Meltdown-and-Spectre-malware-discovered-in-the-wild https://www.techtarget.com/searchsecurity/news/252434342/Mel...
- teruakohatu 1y agoHaven’t browsers closed that hole independently by reducing timing precision?
- anthk 1y agoUBlock Origin with JS turned off, or NoScript. Good luck.