Why isn't the proposed fix "don't allow cross-site iframe injection"? It is surely a security risk that other browsers have taken that stand on no?

disabling CSS/SVG filters for cross-site content also seems like a pretty reasonable thing to do

Does anyone know the use case for cross-site CSS/SVG filters and who would need even need it?

For example you want to display a small blurred thumbnail of an iframe.

Perhaps some things we just shouldn't be allowed to do

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?

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?

95% of the people have no idea what they mean and just click yes.

I love 3d graphics on the web but man it seems to be an infinite security hole

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.

It's not the first time SVG has caused problems. I've had it disabled for a while.

> 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?

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?

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).

Link to original paper:

https://www.hertzbleed.com/gpu.zip/GPU-zip.pdf