Hello,
I found a paper at https://hannesweissteiner.com/publications/frost/ that introduces a new covert channel attack using the browser’s OPFS (Origin Private File System) API in JavaScript to exfiltrate data and perform fingerprinting. I’m curious how this impacts Qubes users.
The abstract is as follows:
Prior work showed that variations in SSD access time can be used to leak information about user activity, e.g., the websites a user accesses, and for covert data transmission. To achieve this, SSD contention side channels require accurate high-resolution timing measurements of I/O operations, e.g., through the io_uring kernel API. However, the impact of these attacks is limited in their requirement for native code execution on the victim’s system.
In this paper, we show that SSD contention side channels can be mounted by a remote attacker from within the browser, without native code execution. Our attack FROST targets the Origin Private File System (OPFS) API in JavaScript, allowing us to create and access files on the disk, within the browser’s sandboxed environment. While a challenge in prior work was to evict the OS page cache, we devise an approach that instead bypasses the page cache, enabling fast SSD contention measurements from JavaScript without any user interaction. To evaluate the effectiveness of FROST on macOS and Linux, we build a covert channel that exfiltrates data from a native application to the malicious website with a true channel capacity of 661.63 bit/s on a Linux machine, and 891.77 bit/s on a macOS machine. To evaluate FROST in a side-channel scenario, we mount a website- and an application-fingerprinting attack on users of macOS systems. We can predict accessed websites with an F1 score of 88.95 %, and accessed application with an F1 score of 95.83 %, demonstrating the privacy implications our attack has on regular users.
Obvious mitigation is to not let websites use OPFS without user permission, but then attacker can make up a legitimate-looking reason for allowing OPFS.
Equivalents of the profile-sync-daemon are a better option - IMO it is harder for the attacker to justify selection of a large file.
I don’t think that it’s secure ultimately, but I can’t help to wonder what happens on a system with zfs ARC.
Another way to mitigate this is to halt all tabs you aren’t looking at. Not sure how to do this, but firefox has the “unload tab” button, maybe there is a way…
In about:config, there is a browser.tabs.unloadOnLowMemory preference that accepts Boolean values, you can change it from false (default) to true. Adjusting the available memory pool within each VM will also directly affect how aggressively the tabs unload in Firefox. The most effective mitigation against FROST within this framework is altering user behaviour so that only one tab is available at any given time.
However, the elephant in the room still lingers. If the site you are viewing is malicious, it does not stop the attack itself, only that other halted background tabs are not pulled into the blast radius. There are also usability trade-offs, particularily breaking ongoing WebSocket connections or other real-time tasks, such as playing audio.
My one-liner from earlier in this topic blocks the attack, full-stop.
What one-liner? You mean setting browser.tabs.unloadOnLowMemory?
Apparently there is also a suggestion to set dom.fs.enabled on privacyguides but I can’t find any docs about this
I already provided a comprehensive response for that, allowing JavaScript in the browser but with various granular mitigations, but it is certainly not a comprehensive solution against the attack going through itself.
After re-reading the paper, it seems the underlying side channel allows fingerprinting of other qubes by any application able to make large disk writes and to use precise timing instruments on its own activity.
Javascript+OPFS is only the obvious mechanism - usable from a website. Other non-browser applications - malicious or compromised - could have the same ability.
I will be revisiting my personal javascript tolerance threshhold, all the same.
Not really. As much as I agree that disabling js is impractical in modern environment, automatically executing code submitted by a stranger on the internet is a broken part of the industry. I don’t believe it can change if you and I disable js in our browsers, but I’ve been wrong before
This is why FROST is even applicable to qubes
It also opens an exfiltration channel, infected networkless qube can transmit data out over SSD latency spikes. Not very useful as a channel, there are better options:
And websites probably aren’t the limit - the way applications access drives is definitely fingerprintable, but I’m not sure how doable it is with measurement resolutions they use in the paper, nor what resolutions are possible.
