4 ms·
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 mit
by 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 agoThe 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.
- scandinavian 7y ago> We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine. They leak in flight data, using a detached spidermonkey engine, patched to make performance.now() return rdtscp at a rate of 1B/s while the victim application is spamming a load string instruction as fast as possible. This does not allow: >any ad network can access any and all memory on your desktop This allows any ad-network to access random bits on the cache line. If the timing mitigation didn't already fix this, it seems impossible to me to get anything useful from it, the precision and bitrate is just too low (which is why the exploit just spams load instructions in a while 1 loop). >and the RIDL exploits don't require special instructions. Weird, in the new addendum it says it uses TSX, and in the PoC it uses XBEGIN. Must be a mistake.