[Research] FROST: Leveraging SSD Timing for Cross-Site/App Tracking via JS
Just came across the research from Graz University of Technology regarding the FROST attack. It’s a fascinating (and terrifying) evolution of side-channel attacks. Essentially, a malicious site can fingerprint user activity by monitoring SSD contention timings using standard JavaScript.
The kicker is that it requires zero permissions—no native code, no extensions. It just sits in a tab and watches for I/O latency spikes caused when you open specific apps or websites.
From a technical standpoint, this exploits the deterministic nature of SSD request handling. By measuring execution time deltas via performance.now(), the attacker can infer background activity.
A simplified check for the availability of these high-precision timers looks like this:
// Checking if high-res timers are available
if (performance.now) {
const start = performance.now();
// Simulate I/O load
for(let i=0; i<10000; i++) { }
const end = performance.now();
console.log(`Latency delta: ${end - start}ms`);
}
Detection is tricky because the traffic looks like normal web browsing. The only real mitigation currently is reducing timer precision via browser flags, but that often breaks legitimate web apps.
Has anyone looked into whether standard endpoint EDR solutions can detect the specific pattern of disk contention queries generated by this type of script, or is this purely a browser-vendor fix?
From a SOC perspective, this is invisible to us. We're inspecting network traffic and process execution, but this is strictly logic-level execution within the browser sandbox.
We might be able to correlate high CPU/Disk usage spikes with browser process IDs, but that's a lot of noise. The most actionable advice for enterprises right now is probably enforcing strict browser policies. You can use Chrome policies to disable SharedArrayBuffer and enforce site isolation, though the performance hit is real.
Interesting angle. I wonder if this requires the page to be cross-origin isolated? If it relies on SharedArrayBuffer for high precision, simply not sending the Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy headers should mitigate it by default for most sites.
If it works with standard performance.now() even after the 'Spectre' clamping (reducing precision to 100us), then SSDs are faster than I thought. I'll have to check the Graz paper for their test environment specs.
We've seen similar timing concepts used in crypto-mining detection scripts.
If you want to test if your fleet is vulnerable, you could check the browser version against known mitigations. Here is a quick PowerShell snippet to check Chrome versions on your endpoints:
Get-ItemProperty 'HKLM:\SOFTWARE\Google\Update\Clients\{8A69D345-D564-463C-AFF1-A69D9E530F96}' | Select-Object pv
Ensure you are on the latest Stable channel; Chromium has been aggressive about clamping timers recently.
The research highlights that FROST specifically targets the Flash Translation Layer (FTL) garbage collection, making it distinct from standard cache attacks. If you're looking to emulate the detection logic without the full PoC, monitoring latency variance in the main thread is key. You can verify if high-resolution timers are exposed by running this in the console:
let t = performance.now();
while(performance.now() - t < 1);
console.log(t.toFixed(5));
If you see microsecond precision without site isolation, you're likely vulnerable to the timing vector.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access