Google has released several prototypes of exploits demonstrating the possibility of exploiting Spectre-class vulnerabilities when executing JavaScript code in the browser, bypassing previously implemented protective methods. The exploits can be used to access the memory of the process handling web content in the current tab. To test the exploit's functionality, the site leaky.page has been launched, and the code detailing the logic is hosted on GitHub.
The proposed prototype is designed to carry out an attack on systems with Intel Core i7-6500U processors running Linux and Chrome 88. Modifications are required to apply the exploit to other environments. The exploitation method is not specific to Intel processors—after appropriate adaptation, the exploit has been confirmed to work on systems with CPUs from other manufacturers, including Apple M1 based on ARM architecture. With minor adjustments, the exploit is also functional in other operating systems and browsers built on the Chromium engine.
In an environment based on standard Chrome 88 and Intel Skylake processors, a data leak from the renderer process responsible for handling web content in the current tab of Chrome was achieved at a rate of 1 kilobyte per second. Additionally, alternative prototypes were developed, such as an exploit that, at the cost of reduced stability, increases the leak speed to 8kB/s by using the performance.now() timer with an accuracy of 5 microseconds (0.005 milliseconds). A variant was also prepared that works with timer accuracy at one millisecond, which could be used to access the memory of another process at a speed of about 60 bytes per second.
The published demonstration code consists of three parts. The first part calibrates the timer to assess the time required to execute operations necessary for recovering data left in the processor cache due to speculative execution of CPU instructions. The second part determines the memory layout used for placing a JavaScript array.
The third part directly exploits the Spectre vulnerability to determine the memory content of the current process by creating conditions for speculative execution of certain operations, the results of which are discarded by the processor after determining a failed prediction, but the execution traces remain in the shared cache and can be recovered using cache content determination methods through side channels that analyze the change in access time to cached and uncached data.
The proposed exploitation technique allows avoiding high-precision timers available through the performance.now() API and does not require support for the SharedArrayBuffer type, which allows creating arrays in shared memory. The exploit includes a Spectre gadget that triggers controlled speculative execution of code and a side-channel leakage analyzer that identifies cached data obtained during speculative execution.
The gadget is implemented using a JavaScript array, where an attempt is made to access an area outside the buffer boundaries, affecting the state of the branch prediction block due to the added size check imposed by the compiler (the processor speculatively performs the access but rolls back the state after the check). To analyze the cache content under conditions of insufficient timer precision, a method is proposed that deceives the Tree-PLRU cache eviction strategy used in processors and allows significantly increasing the time difference when returning a value from the cache versus when the value is absent from the cache by increasing the number of cycles.
It is noted that Google has published a prototype of the exploit to demonstrate the realism of attacks using Spectre-class vulnerabilities and to encourage web developers to apply techniques that minimize risks from such attacks. Google believes that without significant redesign of the proposed prototype, it is impossible to create universal exploits that are ready not only for demonstration but also for widespread use.
To reduce risks, website owners are advised to use the recently implemented headers: Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame-Options, X-Content-Type-Options, and SameSite Cookie. These mechanisms do not directly protect against attacks but allow for isolating website data from leakage into processes where malicious JavaScript code might be executed (leakage occurs from the memory of the current process, which could also handle data from another site opened in the same tab). The main idea is to separate the execution of site code from third-party code obtained from untrusted sources, such as those included via iframe.
Source: opennet.ru
