Comment by vessenes | Hacker News Reader

Comment by vessenes | Hacker News Reader

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.

Again, eww. And, wow!

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

Reply on news.ycombinator.com