Carding 4 Carders
Professional
Researchers from the Georgia Institute of Technology, the University of Michigan, and the Ruhr University have developed an iLeakage attack technique that exploits a vulnerability in Apple's "A" and "M" series ARM processors by opening a specially designed page in the browser. The prototype exploits prepared by the researchers allow you to find out the contents of sites opened in other tabs when running JavaScript code in the browser. For example, the ability to detect the text of an email opened in a tab with Gmail, view the YouTube history, and extract the password inserted by the LastPass password manager in the Instagram login form is demonstrated. The attack is applicable to the Safari browser on macOS systems and any browsers on the iOS platform (Apple's rules require all iOS browsers to use only the WebKit system engine shared with Safari).
Despite the fact that the attack is only applicable to Apple products, it offers a rather interesting way to bypass the timer resolution restrictions in the WebKit engine, which can potentially be useful for circumventing similar restrictions in other browsers. The vulnerability identified in the Apple M1 and M2 chips resembles the classic Spectre v1 vulnerability and also leads to memory leaks when performing operations in speculative mode, which are discarded by the processor in case of incorrect prediction, but traces of their execution are deposited in the processor cache.
In the attack method under consideration, speculative execution made it possible to create a primitive for reading arbitrary 64-bit pointers in the address space of the process responsible for rendering page content in the browser. To get access to the address space of the process where someone else's site is being drawn, a trick is used to open the foreign page under investigation in a pop-up window using the window.open () JavaScript method. In this case, the site was opened not in a separate process, but in the same process with the attacker's code.
As one of the security measures in the WebKit engine, JavaScript can only work with packed 35-bit pointers. To organize access to the entire address space of the process and bypass the 35-bit limit, the researchers used the Type Confusion technique, which allows forcing the JavaScript engine to process an object with an incorrect type. When processing a specially designed JavaScript object, the engine creates conditions that lead to speculative execution of instructions that access the array.
Since the object type does not correspond to the type of array being processed, such actions are blocked under normal conditions, so the code for the Type Confusion attack is placed in the conditional "if" block, which is not activated under normal conditions, but is executed in speculative mode if the processor incorrectly predicts further branching. As a result, the processor speculatively accesses the generated 64-bit pointer, but rolls back the state after determining an unsuccessful forecast. At the same time, traces of speculative execution are deposited in the shared cache and can be restored using methods for determining the cache contents via third-party channels.
To extract data from the CPU's L1 cache remaining after speculative operations, the attack involves a modification of the pLRU (pseudo Least Recently Used) method previously proposed by Google. At the same time, the original pLRU method is tied to measuring delays in accessing data, the difference of which makes it possible to judge whether a certain sequence is in the processor cache or not (if the data is cached, the operation is performed faster, and if not, it is slower). To protect against probing the processor cache in modern browsers, the timer accuracy is significantly reduced to a level that does not allow detecting differences.
To overcome the timer accuracy limitation in the iLeakage attack, a technique is proposed that allows you to determine the presence or absence of data in the cache using a race condition. The essence of the method is to run two threads simultaneously - the main one and the reference one. A reference stream includes a sequence of instructions executed at a specific reference time. At the very beginning of execution of the reference thread, a variable shared with the main thread is set to value 1, and after executing instructions, the variable is reset to zero. So the shared variable only has a value of 1 for a certain short time.
The main thread initiates a loop to determine data in the cache using the pLRU method. A sign of the presence or absence of checked data in the cache is not the time measurement by the timer, but the state of the shared variable after verification. If the variable has a value of 1, then the operation was completed faster than the reference code was executed in a parallel thread, i.e. the data was returned from the cache. If the variable contains the value 0, then the operation was performed for a relatively long time due to the lack of data in the cache and the reference code in the parallel thread managed to fully work out.
The accuracy of the proposed method for determining the cache content is from 90% to 99%, and the data detection performance is from 23 to 34 bytes per second, depending on the processor and device. Before performing an attack, the reference code needs to be calibrated, which takes approximately five minutes. After the calibration is completed for the current system, it takes approximately 30 seconds to extract a 64-character string.
Additionally, you can note the publication of a prototype exploit that uses the Zenbleed vulnerability in AMD processors based on the Zen2 microarchitecture to extract data processed in other processes when opening the exploit page in Chrome. In addition to the Zenbleed vulnerability (CVE-2023-20593), the exploit also involves the vulnerability CVE-2023-3079 in the V8 engine, fixed in Chrome 115.
• Video:
Despite the fact that the attack is only applicable to Apple products, it offers a rather interesting way to bypass the timer resolution restrictions in the WebKit engine, which can potentially be useful for circumventing similar restrictions in other browsers. The vulnerability identified in the Apple M1 and M2 chips resembles the classic Spectre v1 vulnerability and also leads to memory leaks when performing operations in speculative mode, which are discarded by the processor in case of incorrect prediction, but traces of their execution are deposited in the processor cache.
In the attack method under consideration, speculative execution made it possible to create a primitive for reading arbitrary 64-bit pointers in the address space of the process responsible for rendering page content in the browser. To get access to the address space of the process where someone else's site is being drawn, a trick is used to open the foreign page under investigation in a pop-up window using the window.open () JavaScript method. In this case, the site was opened not in a separate process, but in the same process with the attacker's code.
As one of the security measures in the WebKit engine, JavaScript can only work with packed 35-bit pointers. To organize access to the entire address space of the process and bypass the 35-bit limit, the researchers used the Type Confusion technique, which allows forcing the JavaScript engine to process an object with an incorrect type. When processing a specially designed JavaScript object, the engine creates conditions that lead to speculative execution of instructions that access the array.
Since the object type does not correspond to the type of array being processed, such actions are blocked under normal conditions, so the code for the Type Confusion attack is placed in the conditional "if" block, which is not activated under normal conditions, but is executed in speculative mode if the processor incorrectly predicts further branching. As a result, the processor speculatively accesses the generated 64-bit pointer, but rolls back the state after determining an unsuccessful forecast. At the same time, traces of speculative execution are deposited in the shared cache and can be restored using methods for determining the cache contents via third-party channels.
To extract data from the CPU's L1 cache remaining after speculative operations, the attack involves a modification of the pLRU (pseudo Least Recently Used) method previously proposed by Google. At the same time, the original pLRU method is tied to measuring delays in accessing data, the difference of which makes it possible to judge whether a certain sequence is in the processor cache or not (if the data is cached, the operation is performed faster, and if not, it is slower). To protect against probing the processor cache in modern browsers, the timer accuracy is significantly reduced to a level that does not allow detecting differences.
To overcome the timer accuracy limitation in the iLeakage attack, a technique is proposed that allows you to determine the presence or absence of data in the cache using a race condition. The essence of the method is to run two threads simultaneously - the main one and the reference one. A reference stream includes a sequence of instructions executed at a specific reference time. At the very beginning of execution of the reference thread, a variable shared with the main thread is set to value 1, and after executing instructions, the variable is reset to zero. So the shared variable only has a value of 1 for a certain short time.
The main thread initiates a loop to determine data in the cache using the pLRU method. A sign of the presence or absence of checked data in the cache is not the time measurement by the timer, but the state of the shared variable after verification. If the variable has a value of 1, then the operation was completed faster than the reference code was executed in a parallel thread, i.e. the data was returned from the cache. If the variable contains the value 0, then the operation was performed for a relatively long time due to the lack of data in the cache and the reference code in the parallel thread managed to fully work out.
The accuracy of the proposed method for determining the cache content is from 90% to 99%, and the data detection performance is from 23 to 34 bytes per second, depending on the processor and device. Before performing an attack, the reference code needs to be calibrated, which takes approximately five minutes. After the calibration is completed for the current system, it takes approximately 30 seconds to extract a 64-character string.
Additionally, you can note the publication of a prototype exploit that uses the Zenbleed vulnerability in AMD processors based on the Zen2 microarchitecture to extract data processed in other processes when opening the exploit page in Chrome. In addition to the Zenbleed vulnerability (CVE-2023-20593), the exploit also involves the vulnerability CVE-2023-3079 in the V8 engine, fixed in Chrome 115.
• Video:
