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?
Time to write a comprehensive paper titled "Optimizations Considered Harmful".
Seriously though, it's distressing how we have Spectre and Meltdown and whatnot. We've gone too far trying to squeeze every drop of performance out of hardware (Electron is for balance, of course /s) and now we pay the price.
The fact only chromium based browsers are effected makes me think really the problem lies with the browser. However, still using the result of compression as a delta to extract sensitive data is not exactly new.
Yes, I found it interesting that Safari and Firefox are immune. Perhaps this should be framed as another chromium-based exploit rather than a GPU issue.
In this case it's because Chrome supports a relatively obscure use case (GPU-accelerated CSS filters on a cross-origin iframe), it's not really a bug or a vulnerability in the browser.
At the point where you're rasterizing, the distinction between same-origin and cross-origin is not necessarily present. It's possible this just works because it happened to work, and nobody ever went out of their way to implement it.
i.e. the display list for the page has some boxes for iframes, and those boxes are identical to the rasterizer regardless of what origin they're from, so it happily applies filters to all of the iframes.
You seem knowledgeable on this. Why is only chrome supporting this feature and other browsers aren’t? Was this feature pushed by the chrome team?
As for your second point, how is this not a vulnerability in the browser? The security intent is clear, a page should not be able to inspect an iframe. I can’t take a screenshot and read the pixels of the iframe. The fact the chromium supports a published standard is irrelevant. The browser exposes information it is not supposed to and is vulnerable to attack.
The intent of the css feature was not to allow reading iframe pixels. If that cannot be avoided, then the feature is insecure and any browser implementing it has a vulnerability. If it can be avoided then chrome has an insecure implementation.
I don't have any reason to believe that the Chrome team pushed for this use case specifically. In the past when I experimented with SVG filters their feature support was already very different across Trident Edge, Chrome, and Firefox, as was their implementation (hardware accelerated vs not). SVG filters are very powerful and also very slow, and not necessarily constant-time, so they're a good target if you're trying to execute a timing attack. (For whatever reason, my old JSIL project actually happened to use SVG filters to accelerate a specific use case...)
I think it would be fair to call it an oversight that Chromium allows cross-origin use of the features involved in this attack, but it doesn't really feel like a vulnerability in the traditional sense to me - everything is working as intended/specified AFAIK. It just happens to expose a timing attack. The reality is that tons of things are potential timing attacks and if every single feature that might get used for one was disabled in advance the web platform would be pretty useless.
There are various constraints you could apply to make attacks like this harder - i.e. limiting filter stacks to say 4 items, limiting use of filters cross-origin - but I find it understandable that such things didn't happen. This functionality is probably also quite old so it's possible nobody was taking timing attacks quite as seriously back then.
> The reality is that tons of things are potential timing attacks and if every single feature that might get used for one was disabled in advance the web platform would be pretty useless.
I feel like the web platform would be much more useful if I didn't have to constantly worry about drive-by attacks leveraging bugs in a giant stack of "web technologies" that are only getting more complex with each passing year.
Interesting points. However, I think the reasons are much simpler: why wouldn't you want accelerated CSS in your browser, including cross-origin iframes?
Browsers have been making use of GPUs for a long time. It's faster than the CPU and saves battery
Yes, between the device with hardware accelerated rendering and the device without, the user is likely going to prefer the former because software implementations are much slower and much more power-hungry. Thankfully SVG/CSS filters aren't used a ton on the web but usage has probably crawled up over time - I know many websites now use CSS blur filters.
> On AMD’s Ryzen 7 4800U, GPU.zip took about 30 minutes to render the targeted pixels with 97 percent accuracy. The attack required 215 minutes to reconstruct the pixels when displayed on a system running an Intel i7-8700.
The word is used to refer to taking something without the right to do so. The key part is the lack of a right to do so, not depriving the owner.
e.g. If you take someone's car while they're away on vacation and bring it back before they get home, it is still stealing, even if you topped up the tank and they never noticed.
The reason that it is wrong to take my car, even if I don’t notice, are multiple:
- You are still depriving me of the possibility of using my own car, even if it happened to be the case that I didn’t need it. I could have come home early. I could have told some friend or family to pick up my car so that they could use it. I could have had an appointment that someone would come by to service my car while I was absent. All of this is made impossible if someone takes my car.
- It still causes wear and tear on my car if you use it.
- You could get into an accident, which could hurt you and damage my car.
- I don’t want random strangers to sit their butts in my car.
Not to derail further, but iirc that’s not the case in most western jurisdictions (“intended to return it after using” is actually a defence against theft charges).
Yes, in the legal world there are more specific meanings of words (of which "stealing" usually isn't one) which may vary, but we're just talking about colloquial english here.
I know it's a non-serious play on the piracy/theft meme, but in seriousness, "stealing" is probably not the right word for private information leakage.
I think a sentences like "the Russian spy stole American military secrets", "a hacker stole my password" and "a very slow cross-site SVG filter attack stole a copy of my pixels" are perfectly valid and clear English.
Piracy is the odd-one-out because it's about "stealing" non-secret information, which seems non-sensical.
Actually, that brings up a potential problem for me because sometimes I do click the eyeball icon to show my password to myself.
This attack might be too slow as long as I hide the password within 30 seconds, but future versions of the attack might be fast enough to capture multiple characters, especially if the malicious website hosting the iframe knows which pixel positions will be occupied by the password box.
Imagine you're a shady streaming site running tons of shady ads. Now imagine one of your shady advertisers loads a shady iframe using this exploit. The targeted user keeps that tab open for a few hours- they're watching a show, after all. As the streaming site loading the add, you're none the wiser.
JavaScript tends to be fine in specific allow-listed circumstances:
* User preference (E.G. plugins/extensions)
* Native to the site, when a user is logged in
* Trivial and sandboxed to page local data
I recall how I used to use Flash, with a plugin that delayed the loading until AFTER I hit 'play' on the plugin frame.
I suspect that's the sort of security framework that will solve a lot of the problems. Do not run untrusted code by default. Have the user to enable a site (often during account creation / sign in on a new device). Have the user 'click play' if they expect something to work.
Make sites that just work without client side code again.
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!