Security researchers at Graz University of Technology in Austria have published a paper describing a side-channel attack that lets a malicious website identify what other sites and apps a visitor has open by measuring SSD access latency through JavaScript inside a standard browser sandbox. The technique, called FROST (Fingerprinting Remotely using OPFS-based SSD Timing), correctly identified visited websites with roughly 89% accuracy and running applications with roughly 96% accuracy on a test Mac, requires nothing from the victim beyond visiting the attacker's page, and works across different browsers.
FROST exploits the Origin Private File System (OPFS), a browser API that lets websites create and store files on a user's local disk without prompting for permission. Previous SSD side-channel attacks that we’ve seen require native code running through privileged kernel interfaces, but FROST eliminates that requirement.
The team disclosed their findings to Google, Apple, and Mozilla: Google said it doesn't consider fingerprinting a security vulnerability, Apple called the attack "currently out of scope," and Mozilla acknowledged the findings without implementing fixes.
The attack creates a large OPFS file on the victim's SSD, with both Chrome and Safari allowing a website to claim up to 60% of total disk space through OPFS, which on a 256GB drive is over 150GB. The file must exceed the system's available RAM so that every random 4 KB read hits the SSD rather than the OS’s page cache. When other activity generates its own disk I/O, it creates measurable latency spikes in the attacker's reads, and those timing patterns are fed into a convolutional neural network trained to recognize specific websites and applications by their I/O signatures.
Because the contention occurs at the storage level, the attack works across browsers; running the attacker page in Chrome while the victim browsed in Safari showed only a 3.38% throughput difference versus a same-browser attack.
The full fingerprinting attack was only tested on an M2 Mac Mini with 8GB of RAM and a 256GB SSD. On Linux, the researchers confirmed they could measure SSD latency from the browser, but didn’t run the full fingerprinting classification, and Windows wasn’t tested at all. The OPFS file must also reside on the same physical SSD as the monitored activity, which isn’t guaranteed on multi-drive workstations.
By far the biggest barrier to this attack is the large file size; most people will notice tens or hundreds of gigabytes suddenly disappearing, but the researchers propose mitigations, including capping OPFS file sizes to fit within system memory or requiring explicit permission for OPFS file creation. Given that Google doesn’t classify fingerprinting as a security issue, browser-level fixes are unlikely in the near term.
(Score: 5, Funny) by mhajicek on Wednesday June 03, @01:00AM (2 children)
Does this still work when I have 200+ tabs open?
The spacelike surfaces of time foliations can have a cusp at the surface of discontinuity. - P. Hajicek
(Score: 2) by ichthus on Wednesday June 03, @04:43AM (1 child)
Does this work when I'm running a modern operating system that caches to RAM, and not straight to disk?
(Score: 4, Interesting) by Reziac on Wednesday June 03, @06:58AM
I had a similar thought... given the obnoxious and outrageous price of SSD/NVMe storage, and that probably 90% of SSD wear-and-tear is browser activity, I've directed the entire mess to a RAMdisk. Along with OS tempfiles.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 5, Insightful) by Anonymous Coward on Wednesday June 03, @01:20AM (1 child)
The entire premise of a modern web browser is that you should automatically download and run software supplied by strangers on your computer. The web browser promises that this will be "safe" because they essentially contain a massive list of things that such programs are and are not allowed to do (and apparently filling 60% of your total disk space is on the "things that are allowed" list??!).
I'm sure the browser developers will once again "fix" this problem by adding yet another rule to the massive list which prevents this particular form of malware from working. This time I'm sure the lists will be correct, and they won't need to be updated again.
Or maybe we should just not automatically download and execute code supplied by strangers.
(Score: 3, Informative) by Reziac on Wednesday June 03, @01:55PM
As someone's tagline hereabout says, "Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer."
And there is no Alkibiades to come back and save us from ourselves.
(Score: 2) by coolgopher on Wednesday June 03, @04:24AM (3 children)
Why TF would I want a website to be allowed to silently store things on my disk?! It's bad enough with the browser cache. But I guess other peoples' disks are the smart place to store your CSAM 😬
(Score: 2) by Reziac on Wednesday June 03, @07:01AM
And that's another reason why my browser cache goes on a RAMdisk.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 3, Insightful) by Unixnut on Wednesday June 03, @11:39AM
I had similar thoughts, especially the bit that says "a browser API that lets websites create and store files on a user's local disk without prompting for permission."
I mean WTF? Now any random javascript can create files on my OS without my permission (i.e. without my knowledge)? Surely there should be a prompt at least, something like "This website wants to write files to your disk, allow? (y/n)?". That alone would limit this vulnerability simply because a website I would not expect to need local storage would be refused as such.
Its bad enough that we have to execute random javascript off the internet for simple websites nowadays but at least you can argue that it is "sandboxed". However the sandbox is useless if you are going to keep punching holes through it for filesystem-access/GPU-access/network sockets, etc....
At some point you don't have a sandbox anymore you have a colander, and that is about as good at sandboxing as its culinary equivalent would be at holding water.
(Score: 4, Interesting) by VLM on Wednesday June 03, @01:48PM
Its the good idea fairy.
https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system [mozilla.org]
If you get rid of it, they'll just use cookies, lots and lots of cookies. And OPFS is only available over https to the original ("origin") site.
It's "pretty old" by web standards.
If you're arguing a higher level philosophical question like should browser caches exist, should cookies exist, should OPFS exist, well, thats a higher level issue.
I have very little involvement in this. I thought it would be interesting for resource constrained microcontrollers to use OPFS to store stuff offsite in the user's browser. This turned out to be quite impractical as the code to "do" OPFS on a microcontroller was bigger than the storage I'd get from using it. You're gonna need buffers and buffers and more buffers and did I mention buffers this is just impractical.
Like say you want to render a graph of some sensor... I got to thinking, instead of calculate the graph and store the graph on the microcontroller, why not use some javascript bullshit to generate the graph given a list of integer tuples from the sensor on the user's browser and essentially cache it between sensor updates on OPFS so it doesn't have to waste time redrawing. Naw that ain't happening on anything smaller than a raspi which is big enough to do it locally instead of this convoluted nonsense. But it was fun idea to think about/try. I suppose a CLI way of looking at it is I wanted to "rsync" numerical sensor data to OPFS on the viewer's browser, sorta kinda, then render the graph on the user's browser using graphiviz or wtf, using CLI terms, but do it all on a microcontroller, which isn't going to fit in there.
(Score: 2) by VLM on Wednesday June 03, @01:58PM
Its like 1970s TEMPEST except instead of reading CRTs by looking at unique spectrum analysis of RFI and power supply current, they're looking at spectrum analysis of disk latency.
A cool idea. Fundamentally, nothing new under the sun, they're running the same algos for the same goals half a century later using wildly different input sensors.
There's a similar game for crypto where you pound a multitasking CPU with CPU load while watching high precision counters/timers when another process is running a crypto algo. Some algos will leak what they're doing via instruction latency; most multitasking CPUs will not allow interrupts in microcode so you have a fine grained measure of instruction latency if you run it enough times. So if the instruction latency spectrum for "bit 172 of the key is a 1" looks weird compared to if the bit was 0, then looking at instruction counts over time, enough times, will leak if bit 172 is a 1 or 0, repeat 4096 times and you got the "unbreakable" 4096 bit key.
I can probably think of other examples after some morning tea. But yeah, that damn Fourier and his transform, you can turn frequencies into intervals and intervals can leak data.
There are defenses, all of them are icky and slow things down. In the example above, don't calculate just "bit 172 of the key is a 1" calculate both 1 and 0 and randomize the heck out of the order of first real second inverse or first inverse second real. Not a perfect defense but it'll help a little. You can also mask interrupts during crypto which will piss off every other user of the multitasking system. At some point it'll probably come to that.