With cross-origin isolation, the resolutions of perfomance.now() and performance.timeOrigin drop from 100 microseconds or higher to 5 microseconds or higher, thus re-enabling high-resolution timers as well. Because of Spectre, high-resolution timers were disabled as well. But not only that, it also enables asureUserAgentSpecificMemory() to measure your webpage’s total memory usage. Together with HTTPS, cross-origin isolation enables the use of SharedArrayBuffer. Let’s discuss what that entails! Cross-Origin isolation The second requirement is that your document has to be cross-origin isolated. But what comes next is a whole different level. Nowadays, most websites are served over HTTPS so that requirement shouldn’t be too hard to fulfill. If you load a document inside an iframe, its context is not considered secure if an ancestor was not served over HTTPS. In short, this means that the document has to be served over HTTPS. The baseline requirement is that your document needs to be in a secure context. To be able to use SABs, certain requirements have to be fulfilled as they are not enabled by default. Instead, the mechanisms drastically reduce the attack surface by protecting sensitive data from being present in parts of the memory from which they can be read by the attacker. These mechanisms are crucially important however, they don’t prevent the exploitation of the Spectre vulnerability. In 2020, browser vendors re-enabled the use of SharedArrayBuffer after a new secure approach had been standardized. This is the reason why they were disabled in light of this vulnerability. Timing attacks are possible with low-resolution timers, but can be sped up by using high-resolution timers. This, in turn, allows the attacker to read the contents of the process’ memory. Because they share the same context, they are both grouped together which means that they can interact with each other via DOM APIs such as window.opener.īy measuring the time certain operations take, an attacker can guess the contents of the CPU caches. The document opens a popup window which has its own browsing context, but they both share the same parent context. For instance, a document gets rendered inside a tab, that tab is the browsing context. A browsing context group is a group of browsing contexts like tabs, windows or iframes which share the same context. When the protocol, domain, and port of two browsing contexts match, they have the same origin. Every browsing context has a specific origin which is defined by the protocol, domain, and port of the URL. This is usually a tab but can also be a window or an iframe. Spectre allows an attacker to potentially read any data that is loaded inside the same browsing context group.Ī browsing context is an environment in which a browser renders a document. One of its features is that it allows for synchronous communication between workers by leveraging the Atomics APIs.Īt the beginning of 2018, SharedArrayBuffer was disabled together with high-resolution timers by all browser vendors in light of the Spectre vulnerability. A SharedArrayBuffer represents a raw binary data buffer which can be shared with, for instance, multiple Web Workers. Under the hood, WebContainers use SABs heavily for communication. SharedArrayBuffer is available in all browsers, however, it’s not available by default. There’s one crucial part that WebContainers need in order to work, which is SharedArrayBuffer, or SABs. To understand all of this, we have to look inside the technology stack that we use. As much as we ourselves want this technology to work across all browsers, it’s not as simple as just turning on a few knobs. Some people think it’s because we use Chrome-specific APIs to make WebContainers work, which is not the case. Since the release of WebContainers about a year ago, we have been regularly asked why they don’t work in non-Chromium browsers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |