https://wiki.mozilla.org/Security/Sandbox See that trust boundary, security Sandboxing makes use of child processes as a security boundary. The security hole bypasses security boundaries. You have made the most pointless point ever.
From the white paper, the one you never read, "Moreover, we present a number of practical exploits that leak data across many common security boundaries (JavaScript sandbox, process,kernel, VM, SGX, etc.). " "Finally, we assume the attacker can only run unprivileged code on the victim system (e.g., JavaScript sandbox, user process, VM, or SGX enclave)"
"As shown in the listing, the code is normal, straight-line code without invalid accesses (or, indeed, error suppression), which, as we will show, can also be implemented in managed languages such as JavaScript."
" Not to mention that such attacks can be built even from a sandboxed environment such as JavaScript in the browser, where the attacker has limited capabilities compared to a native environment."
"G. JavaScript attacks To further demonstrate the implications of RIDL, we show that RIDL can be exploited even within restricted sandboxed environments such as JavaScript. In recent years, browser vendors have been proactively working on mitigations to protect against side-channel attacks [62],[63], [64], [65]—speculative execution side channels, in particular. For instance, Chrome fast-forwarded the deployment of process-per-origin [63] as a mitigation against Spectre attacks. However, these mitigation efforts assumet hat data cannot leak across privilege boundaries, and fail to prevent in-flight data from being leaked with RIDL.Building a RIDL attack from the browser requires a high level of control over the instructions executed by the JavaScript engine. Conveniently,WebAssembly allows us to generate code which meets these requirements and is available as a standard feature in modern browsers. We found that we can use WebAssembly in both Firefox and Chrome to generate machine code which we can use to perform RIDL-based attacks. Furthermore, all the major browsers try to reduce the memory footprint of the WebAssembly heap by relying on demand paging [60], which we can use to perform an attack along the lines of the one previously presented in Listing1. That is, we can rely on the valid page fault generated by our memory access totrigger an exception and spill the in-flight data.Generating the correct machine code and triggering the page fault are relatively straightforward. However,constructing a reliable feedback channel for speculative attacks within the browser presents some challenges. The absence of the clflush instruction forced our implementation to rely on anEvict + Reload channel to leak the in-flight data. Since the process of evicting entries from the L1D cache makes extensive use of the LFBs—due to TLB misses as well as filling cache lines—this adds a significant source of noise. We also need to ensure that the TLB entries for our reload buffer are still present after the eviction process, adding another source of noise to our attack. Finally, we need a reliable high-resolution timer to measure cache evictions for our Evict + Reload channel.While built-in high-resolution timers have been disabled as part of browser mitigations against side-channel at-tacks [64], [63], prior work has demonstrated a variety of techniques to craft new high-resolution timers [66],[56], [60], such as Shared ArrayBuffer [60] and GPU-based counters [56]. The SharedArrayBuffer feature was recently re-enabled in Google Chrome, after the introduction of Site Isolation [67], [68]. Mozilla Firefox is currently working on a similar Process Isolation strategy [69]. Despite these challenges, we successfully implemented a proof-of-concept exploit on top of Firefox’ SpiderMonkey JavaScript engine to reliably leak data from a victim process running on the same system. For simplicity, our exploit uses an old-style built-in high-resolution timer in SpiderMonkey to measure cache evictions. When targeting a victim process repeatedly writing a string to memory, our exploit running in the JavaScript sandbox on a different hardware thread is capable of leaking the victim string ata rate of ~1B/s. We also implemented a high-resolution timer in Chrome using WebAssembly threads which provided sufficient accuracy for our Evict + Reload channel. At the time of writing, any site can opt into this functionality using the ‘origin trials’ system. Although we do not currently have a reliable RIDL exploit running inside unmodified Chrome, we believe that our results already cast doubt on the effectiveness of site isolation as a mitigation against side-channel attack..." https://mdsattacks.com/files/ridl.pdf
The admin on this forum is weak normally you lot would be banned by now.
Last edited:
literally anything on the internet can be turned into an argument that spans days or more, at this point it's a battle of attrition where only few men dared to go. It's been an epic read but I left the front lines for fear of shooting myself in the face...
I consider myself warned and have given myself a stern dressing down, my behaviour was uncouth and I should be punished for my transgressions towards my fellow overclockers.