Google unveiled several days ago various exploit prototypes that demonstrate the possibility of exploiting vulnerabilities of the Specter class when executing JavaScript code in a browser, without going through the security methods added above.
Exploits can be used to access the memory of a process which is processing web content in the current tab. To test the operation of the exploit, the website for the leaky page was launched and the code describing the logic of the operation is published on GitHub.
The proposed prototype is designed to attack systems with Intel Core i7-6500U processors in a Linux and Chrome 88 environment, although this does not exclude that changes can be made to use the exploit in other environments.
The method of operation is not specific to the processors Intel: after proper adaptation, The exploit has been confirmed to work on systems with third-party CPUs, including the Apple M1 based on the ARM architecture. After minor tweaks, 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, we achieved a data leak from the process responsible for rendering web content in the current Chrome tab (rendering process) at a speed of 1 kilobyte per second. In addition, alternative prototypes were developed, for example, an exploit that allows, at the cost of reduced stability, to increase the leak rate to 8kB / s when using the performance.now () timer with a precision of 5 microseconds (0.005 milliseconds ). A variant was also developed that operated with a timer precision of one millisecond, which could be used to organize access to the memory of another process at a rate of about 60 bytes per second.
The published demo code consists of three parts:
- The first part calibrate the timer to estimate the running time of the operations necessary to retrieve the data that remains in the processor cache as a result of the speculative execution of the CPU instructions.
- The second part Defines the memory layout used when allocating the JavaScript array.
- The third part directly exploits the Specter vulnerability to determine memory content of the current process as a result of the creation of conditions for the speculative execution of certain operations, the result of which is discarded by the processor after determining a failed forecast, but the execution traces are settled in the shared cache and can be restored using methods to Determine the contents of the cache using third-party channels that analyze the change in access time to cached and non-cached data.
The proposed exploitation technique eliminates high-precision timers available through the performance.now () API and without support for the SharedArrayBuffer type, which allows you to create arrays in shared memory.
The exploit includes the Specter device, which causes controlled speculative code execution, and a side channel leak analyzer, which determines what data has been cached during speculative execution.
The gadget is implemented using a JavaScript array, in which an attempt is made to access an area outside the limits of the buffer, which affects the state of the branch prediction block due to the presence of a buffer size check added by the compiler (the processor speculatively performs an access ahead of time, but reverts the state after checking).
To analyze the contents of the cache under conditions of insufficient timer precision, a method was proposed that tricks the Tree-PLRU cache data eviction strategy used in processors and allows, by increasing the number of cycles, to significantly increase the difference time when the value is returned from the cache and in the absence of a value in the cache.
Google has published a prototype of the exploit to show the feasibility of the attacks using Specter class vulnerabilities and encourage web developers to use techniques that minimize the risks of 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.
Source: https://security.googleblog.com