Microarchitectural attacks have been greatly explored over the last years. They can have a great impact on security by allowing attackers to circumvent system isolation. However, to mount such an attack, the attacker must run code on the victim's machine, which is a strong condition in today's systems, where users grew distrustful of unknown code.

In this post, we show how we developed port-contention side channels by running them entirely in JavaScript, dramatically widening its threat surface. We explain how we solved the challenges brought by the browser sandbox, and show concrete examples of port contention attacks. In particular, our attack shows the fastest covert channel in the browser, thus breaking the isolation model at the core of modern browsers' security model. With this covert channel, an attacker can exchange cookies with other tabs or leak secret information.

Microarchitectural Side Channels

Modern processors are highly optimized pieces of hardware. With the evolution of computing, they have remarkably shrunk while offering exponentially greater computation power. To allow greater performances without changing the frequency of the CPU, hardware vendors have developed a wide range of specific optimizations, in order to reduce the execution time of certain operations.

However, these optimizations can leak sensitive information. As they are situated below the software security brought by the OS, these optimizations are shared between the users. A malicious user can exploit differences in computation time to retrieve secret information. These microarchitectural side channels can target many different hardware components, but most of them share two major prerequisites:

• A high-resolution timer to detect the subtle timing differences caused by optimizations. Generally speaking, these attacks require a resolution of a few nanoseconds.
• Running malicious code on the victim's machine, in order to use its hardware.

The most well-known example of microarchitectural side channels is based on the CPU Cache. The cache is a very small (around 64 MB), high-speed memory. It is used to dynamically store the values of often-used values, as loading data from the cache is faster than from the DRAM. The cache is shared by all processes on the machine. A malicious user can measure the loading time of certain addresses to monitor other processes: if an access is quicker than usual, it means that the address is in the cache, i.e., another process used it recently. These attacks can allow a process to monitor other processes, or retrieve cryptographic secrets. Recently, transient-execution attacks, such as Spectre, often use microarchitectural side channels to extract sensitive information.

Port Contention

Port contention is a microarchitectural side channel first described by Aldaya et al. in 2019. It exploits HyperThreading, a technology allowing, at an abstract level, to create two or more logical execution threads on a single physical core. This means that, at the OS level, each physical core offers several threads, but logical threads on the same core share all hardware components in the execution pipeline.

Port contention exploits the CPU ports. Figure 1 presents an abstracted view of the execution pipeline for a single physical core. Thread 1 and thread 2 are both HyperThreading logical threads. The decoder fetches the instruction to execute and decompose them in micro-operations (or uops), a smaller, more atomic form of operation. Then, the uops are sent to the execution engine to be executed. The execution engine is composed of a various number of execution units. Each execution unit is specialized for a certain type of operations, e.g., arithmetical operations or memory loads. The uops are transmitted to their associated execution units through CPU Ports. These ports act as a bottleneck, as a single uop can go through a port per cycle.

By repeatedly calling and timing instructions with a specific port usage, an attacker can monitor the port usage of other processes on the same core. Figure 2 illustrates the process. When no other processes emit uop on port 1, as in Figure 2.a, all the attacker uops are executed in a row, resulting in fast execution. However, when the victim emits an uop on port 1, as in Figure 2.b, the second attacker uop is delayed in the queue, resulting in slower execution. In this simplified scenario, the attacker can know whether or not the victim used instructions with port 1 usage. Using this principle, Aldaya et al. mounted an attack against OpenSSL's TLS implementation to recover private keys. Port contention was also leveraged to mount a speculative execution attack in SMoTherSpectre.

Port Contention in Browsers

Challenges

As all microarchitectural attacks, port contention requires running code on the victim's hardware. This is a strong assumption for native attacks, as users rarely download and run malicious code voluntarily.

The main contribution of our paper is to implement port contention in a web setting. Client-side languages, such as JavaScript or Web-Assembly, are by design meant to be downloaded automatically from a web server and run on the client's hardware. This allows to fulfill one of the prerequisites for microarchitectural attacks, thus substantially increasing their threat surface. However, in the case of port contention, this also introduces new challenges:

• [C1]: Port contention attacks, like most timing attacks, require access to high-resolution timers, which are not available by default in the browser.
• [C2]: The high level of abstraction of the browser means that the attacker can neither know nor control on which core the code is run.
• [C3]: Client-side languages are run inside of a secured sandbox, restricting access to native instructions and memory addresses or port usage.

High-resolution timers - C1

Schwarz et al. show how an attacker can reconstruct high-resolution timers in the JavaScript language by using SharedArrayBuffers. They are array shared between the main JavaScript thread and Web Workers, Javascript multithreading implementation. A Web Worker is created and increments a value in the array in a continuous loop. As the duration of the increment is relatively small and steady, we can use it as a time measurement. When the main thread needs a timestamp, it just has to read the shared value.

This clock has a resolution of 10 nanoseconds, which is sufficient to mount our attack, thus resolving C1. However, it is less precise than native clocks and the continual increments reintroduce noise that can deteriorate the results.

Core management - C2

As port contention exploits shared components inside a physical core, we need both the attacker and the victim on the same core. Due to its sandbox design, JavaScript or WebAssembly do not allow the user to know or control on which core the code is running.

We can, however, exploit the OS's scheduler to try and have both parties on the same core. The scheduler dynamically dispatches software tasks between cores. The scheduler heuristics are complicated, but its goal is to balance the workload between all cores to enhance performance. By creating several WebWorkers running port contention computations, they have a high probability of being set on different cores, as they require heavy computations. This ensures that at least one of them shares a physical core with the victim.

PC Detector - C3

JavaScript and WebAssembly are high-level languages. They offer a strong abstraction from memory management, data structure, or hardware. This is highly practical on the web to build simple and portable scripts running in the browser. However, in our attack scenario, it prevents us to know what really happens at the microarchitecture level. In particular, we don't know the translation of our WebAssembly instructions in native x86 instructions, nor the micro-operations or port usage of our script.

To create and exploit contention, we must find instructions that are decomposed in uops dispatched in a specific port. To do so, we built PC-Detector, a framework automatically testing all available instructions for a system, and testing if the instruction creates contention on a specific port.

To detect contention on the web, we use known native instructions paired with unknown WebAssembly instructions. For instance, native vpermd emits one micro-operation on port 5. If we detect contention when repeatedly calling both vpermd and our WebAssembly instruction, this means our WebAssembly instruction emits at least one micro-operation on port 5.

By repeating this operation for all instructions on different ports, we were able to identify instructions creating contention on port 0, port 1, port 23, port 5, and port 6 on an Intel Skylake CPU.

Proof of concepts

We now know that port contention can be achieved in the browser.
We can even target several ports to try to leak more data.
However, this is still a basic building block, an attack vector.
To illustrate the capacity of port contention in the browser, we created two proofs of concept: a covert channel and an artificial side-channel example.

Artificial Side Channel Gadget

Programs often change behavior based on user input or environment values. For instance, vulnerable cryptographical implementations will not execute the same computations based on the secret key. This difference in behavior can be detected indirectly through leaks of information in side-channel attacks.

We built a synthetic and generic example (Fig. 4) showing how a program, which execution depends on secret information, is vulnerable to WebAssembly port contention. The victim is a native unprivileged program, running different code sections based on the bits of secret information. As port usage differs between branches, an attacker monitoring port contention can infer the secret. One branch will execute the POPCNT instruction in a loop, creating contention on port 1. The other branch executes VPERMD, creating contention on port 5. By measuring port contention on either port 1 or 5 in the browser, we can detect which branch was executed, and infer the associated secret.

The victim and the attacker are two different processes. This means that the attacker does not know on which core the victim runs, and must measure contention on all cores and analyze all the traces.

The smallest number of instructions detectable in a branch is critical, as it represents our spatial resolution. A high resolution means that more pieces of code are vulnerable, hence widening the attack scope. At best, in a single trace setting, we achieved a spatial resolution of 1024 native instructions, i.e., 3072 bytes. This number is on par with other microarchitectural side channels in the browser, such as the Prime+Probe cache attack.

Covert Channel

A covert channel exploits data leakage in the microarchitecture to create a communication channel between two parties that should not be able to communicate. In our case, a script running inside of the sandbox could communicate with a native program through port contention. This can be particularly threatful as it could be used to monitor users, steal cookies or extract sensitive data.

The physical layer of our channel, i.e., sending 0s and 1s, is fairly simple. A sender creates contention on a specific port for a specific time to send a 1 and idles for the same time to send a 0. The receiver just has to measure contention on this port to receive the flow of information.

We've built a two-way covert channel from the browser to the native program. It handles errors and desynchronization with a request to send protocol and offers a bandwidth of 200 bits per second, which is higher than other microarchitectural (or even software!) covert channels in the browser.

Our covert channel also works when one of the two parties is situated inside a VM or a container, and we can even communicate between two different browsers or two tabs in the same browser.

Countermeasures

Countermeasures for this vulnerability could potentially be implemented at three different levels:

• Hardware level: At its very core, port contention exploits the sharing of CPU ports between a victim and an attacker, relying heavily on HyperThreading. Some parties have chosen to disable it totally, but it comes at a high-performance cost, bringing a performance degradation of 15%. Research have proposed alternative solutions, mainly based on still implementing HyperThreading but partitioning the resource so they are not shared.

• OS Level: At the OS/Software level, some have suggested port-independent code, i.e., that the port usage does not differ based on a secret. However, this means rewriting all pre-existing code and training all software developers. The scheduler could also be aware of SMT attacks and, for instance, allow highly sensitive operations to run on different physical cores than other computations.

• Browser Level: After the publication of previous microarchitectural attacks in the JavaScript sandbox, several countermeasures have been implemented. A popular solution is to remove access to high-resolution timers. However, we've seen that it is no easy task as auxiliary timers can always be built. Browser vendors also tried to add more isolation, mainly at the process level, but it has little to no impact on port contention attacks. Browser vendors claim that granted the high level of abstraction of browsers, browser-level mitigations are not viable and result in too much cost for low results.

Useful Links

• Full Paper
• Videos: AsiaCCS Video (17 minutes) or Sosysec Seminar (30 Minutes)
• Code

Browsing the web exposes us to constant tracking. In recent years, and due in large part to the general public's interest in their privacy on the web, tracking methods have been scrutinized, new techniques being regularly revealed. Along with colleagues from the Ben-Gurion University of the Negev and the University of Adelaide, we uncovered a new threat to privacy that can efficiently fingerprint your GPU, making you more identifiable on the Internet.

In a nutshell, our newly discovered technique that we named DrawnApart measures the time it takes for the GPU to draw specific points in a 3D environment. What we found is that even devices with the exact same GPU present noticeable variations that can be used to track users on the web. Notably, in our paper, DrawnApart can extend by up to 67% the tracking time of a device compared to known methods.

Tracking on the web

Tracking on the web is nothing recent. As far back as 2001, the New York Time shared concerns about the growing use of cookies on the web. The rapid adoption of the Internet has only made things worse and tracking keeps evolving towards more advanced techniques.
Cookie-based tracking has been the most widespread: from a simple technique, when introduced, it has changed over time to become a complex pipeline of first-and third-party cookies that allows for very precise tracking across the web. Fouad et al. explain in great detail most of the advanced cookie-based tracking techniques that are available on the modern web. Advertisers and trackers exploit these possibilities, making cookie-tracking still the most widespread and effective tracking method.
However, as users start to realize that their privacy is at risk from constant targeting and tracking, browsers are starting to take a stand against these practices. For instance, private browsing modes have been introduced in all major browsers and allow users to wipe data persisted by websites during the browsing session. Other actors in the market have taken a harsher stand: the Brave browser embeds an ad-blocker to restrict most of the tracking and the unwanted advertising. The Tor browser includes much stricter options to limit tracking, at the cost of speed and breakages. Safari and Firefox have also included many features to reduce tracking, like limiting third-party cookies.

This newly shed light on cookie-tracking and the self-awareness of users has pushed advertisers to look towards other techniques to track users. A potential candidate that has been studied is browser fingerprinting. Its stateless nature makes it more difficult to block than cookies, nothing is stored on the client device, while proving to be able to discriminate devices. The Am I Unique platform provides a testing tool that outlines the uniqueness of your setup.
One of the difficulties of browser fingerprint tracking is its limited stability. As attributes evolve over time, it becomes harder to keep track of a device, because the fingerprint changes frequently. This can be countered by choosing a specific set of stable attributes or by taking advantage of hardware-based attributes, which are significantly more stable and arguably more difficult to consistently forge.

We found one such hardware based method we call DrawnApart. Our work outlines how the WebGL API can be exploited to generate a GPU fingerprint through JavaScript. This, combined with other attributes, provides a significant boost of over 66% to the average tracking time over the state-of-the-art algorithm for browser fingerprint tracking (our previous work, called FP-Stalker).

What is DrawnApart ?

DrawnApart is a Graphic Processing Unit (GPU) fingerprinting technique which attempts to uniquely identify your graphics card. It can be run using unprivileged JavaScript in the browser and takes advantage of the WebGL API, which is enabled by default on all the browsers. In our research paper, which is to be presented at the Network And Distributed System Security Symposium 2022, we show that DrawnApart is able to extend by almost 67% the average tracking time of the state-of-the-art. More importantly, we can find differences in what would be otherwise identical hardware (e.g., the same model and version of GPUs from the same vendor, in the purchase order). DrawnApart is able to function for both dedicated or integrated GPUs.

To better understand how DrawnApart works, it is important to understand that GPUs consists of highly parallelized architectures, composed of various Execution Units (EU). Those can all perform independent operations simultaneously. On the software side, WebGL is a cross-platform API for 3D rendering that is implemented in most major browsers. WebGL abstracts the process of rendering into a multi-step pipeline. Two of those steps are exploited by DrawnApart: the vertex shader and the fragment shader. The first takes care of positioning a point in an area, while the second mainly determines the color.

The first step in the DrawnApart fingerprinting process is to instruct the WebGL API to draw a number of points in parallel. For most points, the vertex shader returns as expected, however, for a specific set of points, we execute a stall function which significantly pauses the rendering process. Since a non-stalled point instantly returns, a timing measurement for the set of points is dominated by the time taken by the stalled points to execute. DrawnApart then builds a trace by repeating this drawing process multiple times. The official demo shows the result of this process. This trace can then be used as a GPU fingerprint.

Exploiting the trace

DrawnApart is evaluated in two scenarios, as described in the paper. First, in a controlled environment to better control different variables. The controlled environment is composed of different groups of devices, all equipped with identical GPUs (within a same group) that DrawnApart intends to distinguish.
For this purpose, the evaluation consists in correctly classifying devices by using a  Random Forest classifier. The following table present the resulting accuracy gain over the base rate and shows how DrawnApart provides a significant boost in  identifying capabilities in the controlled environment.
Note we mention three type of timers: onscreen, offscreen, and GPU. Each of these timing methods comes with its advantages: the onscreen method makes use of Window.requestAnimationFrame, which is called after the rendering is done. Measurements are recorded once an iteration of the method has been completed. The onscreen method is compatible with all the major browsers, but present the limitation of a capped refresh rate (to the browser's maximum frame rate). Consequently, one element of the trace must take at least 16ms to be correctly measured.
The offscreen method is more limited in term of compatibility at the time of writing, as it works mostly with Chromium browsers and is subject to manual activation on Firefox.
The GPU timing technique is a variation of the offscreen method that measures the duration of a set of graphics commands directly on the GPU side (as opposed as a measure on the CPU side for both previous methods). However, this method presents serious disadvantages as it strongly varies between different GPU architectures and is not supported anymore by the Google SwiftShader renderer.

The second scenario, which is much more representative of the real world, uses traces collected in the wild through the Am I Unique extension. The extension performs  a scheduled data collection in the background comprised of attributes shown on the Am I Unique fingerprinting page and 7 DrawnApart traces at each collection. As such, the collected dataset is representative of a real world setting with various users from different parts of the globe, with different hardware and software configurations and a realistic computing load. We collected data from over 2,500 devices, with more than 1,605 distincts GPUs, the main task is to be able to distinguish and consistently track the users over time. This scenario provides additional challenges compared to the controlled environment as an attacker (in this case, we are acting as the attacker) cannot use long training phases as the user must be identified in real-time. The attacker should also handle new devices as they arrive, without having to retrain his classifier each time.
In order to respond to those challenges, we proposed a pipeline consisting of an embedding neural network that takes the raw traces as input, and outputs an embedding of the trace in euclidean space. Consequently, the attacker simply has to compute the Euclidean distance between an incoming trace and the traces he previously collected and stored. He basically compares the similarity of the GPU fingerprint. If the Euclidean distance is below a threshold, two traces are very similar and are classified as originating from the same device.
We chose to evaluate DrawnApart in the wild in two steps. First, we evaluate our system without any additional information other than the processed trace (through the previous pipeline) on a k-Nearest Neighbor classifier and we compare the resulting accuracy to a base rate. We find that DrawnApart significantly improves on the base rate.
Second, we evaluate our method when integrated into a browser fingerprint tracking algorithm, namely FP-Stalker, which is the state-of-the-art algorithm for linking browser fingerprints over time.

Compared to the original version of FP-Stalker, our DrawnApart algorithm offers a boost of almost 67% on the average tracking time.

Countermeasures

While the effectiveness of DrawnApart introduces serious privacy risks for users, a number of countermeasures could address these issues:

• Blocking JavaScript is an effective countermeasure, and most browsers and extensions allow blocking JavaScript. This is a rather radical solution that comes with the downside breaking a lot of sides since most websites heavily rely on JavaScript for displaying their content or maintaining a good user experience. You can also look to browser extensions to enable/disable JavaScript at a more granular level (choose which scripts to allow). NoScript is a big favorite, and uMatrix is nice too!
• Disabling the WebGL API could be a good tradeoff compared to blocking all JavaScript. However, it is to be noted that even if only 1% of the Alexa Top 10k showed any usage of the WebGL API, disabling it completely could introduce unexpected breakage. Firefox and a few other browsers already allow users to deactivate the WebGL API.
• Introducing random variation of the clock speed would also be an efficient countermeasure. DrawnApart's traces already contain some noise, and thus, introducing random variations in clock speed would make the data even noisier and thus less exploitable.
• Preventing parallel execution would directly impact the inner working of our technique. However, this countermeasure comes with the heavy cost of severely limiting the performance of the WebGL API.

It should be noted that current mitigations against Canvas Fingerprinting that introduce noise in renderings (see Brave's farble output) cannot be applied against DrawnApart as it is based on measuring execution time and not on comparing rendered images.

Conclusion

Throughout our paper, DrawnApart is shown to efficiently identify devices both in a controlled environment and in real-world scenarios. We show the technique works against what are otherwise identical devices. Through our data collection performed on the Am I Unique platform we showed it is feasible in practice. DrawnApart offers a boost of almost 67% to the average tracking time of the state-of-the-art browser fingerprinting algorithm, outlining the importance of hardware fingerprinting in web tracking.

DrawnApart Demo

In the following video, Vitaly Dyadyuk, co-author of the paper, swaps the CPUs (with integrated graphics) of two identical computers showing that DrawnApart is able to detect a full CPU swap.

Useful links & media coverage

• Full paper: HAL, Arxiv
• Paper's official webpage (orenlab.sise.bgu.ac.il)
• Official artifacts (github.com)

DrawnApart has received media coverage, most notably:

• TheHackerNews (by Ravie Lakshmanan)
• BleepingComputer (by Bill Toulas)
• PCGamer (by Jacob Ridley)
• Gizmodo (by Lucas Ropek)
• SecurityLab.ru (in Russian)
• Gigazine.net (in Japanese)
• Sohu.com (in Chinese)
• Heise Online (in German)
• 01net (French)
• Clubic (French)
• Reddit 1 2 3 4