First browser-based side-channel attack against Apple’s M1 Macs works even with Javascript disabled

A team of researchers has demonstrated a new browser-based side-channel attack that works even if Javascript is blocked, one that affects hardware platforms including Intel Core, AMD Ryzen, Samsung Exynos, and even Apple’s M1 chips.

Taha Broach for The 8-Bit:

To demonstrate the attack, researchers developed a sequence of attacks with decreased dependence on Javascript features which led to the “first browser-based side-channel attack which is constructed entirely from Cascading Style Sheets (CSS) and HTML, and works even when script execution is completely blocked.

This vulnerability may lead to microarchitectural website fingerprinting attacks, the researchers say. A website fingerprinting attack allows an eavesdropper to determine the target’s web activity by leveraging features from the target’s packet sequence. This also effectively disregards the application of most privacy-protecting technologies such as VPNs, proxies, or even TOR.

Among all the efforts made by browsers to block Javascript-based side-channel attacks, the easiest option is to disable Javascript entirely. Apple, for instance, offers an option within Safari settings on macOS to disable Javascript entirely as a way to mitigate such attacks.

Despite that, the new form of the attack demonstrated by researchers from universities in the United States, Australia, and Israel is effective as it only relies on CSS and HTML, making it the first side-channel attack that works on Apple’s M1 chips.

MacDailyNews Take: According to the report, the researchers notified all of the impacted chip vendors. Apple responded stating that the public disclosure of their findings does not raise any concerns:

“We hypothesize that the M1 architecture makes use of less advanced cache heuristics, and that, as a result, the simplistic memory sweeps our attack performs are more capable of flushing the entire cache on these devices than they are on the Intel architecture. Cache attacks cannot be prevented by reduced timer resolution, by the abolition of timers, threads, or arrays, or even by completely disabling scripting support. This implies that any secret-bearing process which shares cache resources with a browser connecting to untrusted websites is potentially at risk of exposure.”