Google has published several exploit prototypes showing the possibility of exploiting Specter class vulnerabilities when executing JavaScript code in a browser, bypassing previously added protection methods. Exploits can be used to gain access to the memory of a process that is processing web content in the current tab. To test the operation of the exploit, the site leaky.page was launched, and the code describing the logic of the work was posted on GitHub.
The proposed prototype is designed to attack systems with Intel Core i7-6500U processors in a Linux and Chrome 88 environment. Changes are required to apply the exploit to other environments. The method of exploitation is not specific to Intel processors - after appropriate adaptation, the exploit was confirmed to work on systems with CPUs from other manufacturers, including the Apple M1 based on the ARM architecture. After minor adjustments, the exploit also works on other operating systems and other browsers based on the Chromium engine.
In an environment based on standard Chrome 88 and Intel Skylake processors, data was leaked from the process responsible for processing web content in the current Chrome tab (renderer process), at a rate of 1 kilobyte per second. Additionally, alternative prototypes were developed, for example, an exploit that allows, at the cost of reducing stability, to increase the leak rate to 8kB/s when using the performance.now() timer with an accuracy of 5 microseconds (0.005 milliseconds). A variant was also prepared, working with a timer accuracy of one millisecond, which could be used to organize access to the memory of another process at a speed of about 60 bytes per second.
The published demo code consists of three parts. The first part calibrates the timer to estimate the execution time of the operations required to restore data left in the processor cache as a result of speculative execution of CPU instructions. The second part determines the memory layout used when allocating the JavaScript array.
The third part directly exploits the Specter vulnerability to determine the contents of the memory of the current process as a result of creating conditions for the speculative execution of certain operations, the result of which is discarded by the processor after determining an unsuccessful prediction, but execution traces are deposited in the general cache and can be restored using methods for determining the contents of the cache by third-party channels that analyze changes in access time to cached and non-cached data.
The proposed exploitation technique eliminates the high-precision timers available through the performance.now() API, and without support for the SharedArrayBuffer type, which allows creating arrays in shared memory. The exploit includes the Specter gadget, which causes controlled speculative code execution, and a side-channel leak analyzer, which determines the data obtained during the speculative execution that got into the cache.
The gadget is implemented using a JavaScript array, in which an attempt is made to access an area outside the boundaries of the buffer, affecting the state of the branch prediction block due to the buffer size check added by the compiler (the processor, looking ahead, speculatively performs the access, but rolls back the state after the check). To analyze the contents of the cache under conditions of insufficient timer accuracy, a method is proposed that deceives the Tree-PLRU cache eviction strategy used in processors and allows, by increasing the number of cycles, to significantly increase the difference in time when returning a value from the cache and when there is no value in the cache.
It is noted that Google published a prototype exploit in order to show the realism of attacks using vulnerabilities of the Specter class and to encourage web developers to use techniques that minimize the risks from such attacks. At the same time, Google believes that without a significant revision of the proposed prototype, it is impossible to create universal exploits that are ready not only for demonstration, but also for widespread use.
To mitigate risk, site owners are encouraged to use the recently implemented 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 Cookies. These mechanisms do not directly protect against attacks, but allow isolating site data from leakage into processes in which the attacker's JavaScript code can be executed (the leak occurs from the memory of the current process, in which, in addition to the attacker's code, data from another site opened in that same tab). The main idea is to separate in different processes the execution of the site code from third-party code obtained from unreliable sources, for example, included through an iframe.
Source: opennet.ru