Could we, like, do away with iframes?
Portals were (are?) an attempt to do this. Haven't heard much about them in a while: https://github.com/WICG/portals#summary-of-differences-betwe...
Sidechannel pixel-stealing attack works in Chromium on all modern GPUs
21–30 of 71 posts
Re: Sidechannel pixel-stealing attack works in Chromium on all modern GPUs
#22Could we, like, do away with iframes?
Please delete JavaScript while we're at it.
Re: Sidechannel pixel-stealing attack works in Chromium on all modern GPUs
#23Has anyone made a law about this sort of thing yet?
If not I'll have it:
Axons Law - Any sufficiently fast optimisation will be repurposed as an attack vector.
Re: Sidechannel pixel-stealing attack works in Chromium on all modern GPUs
#24We should have never gone past Gopher :)
What is it with these strangers who want to run stuff on my computer without my explicit permission?? :-)
Re: Sidechannel pixel-stealing attack works in Chromium on all modern GPUs
#25This 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!
Re: Sidechannel pixel-stealing attack works in Chromium on all modern GPUs
#26This 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 banki…
I love 3d graphics on the web but man it seems to be an infinite security hole
Re: Sidechannel pixel-stealing attack works in Chromium on all modern GPUs
#27Earlier quoted context omitted.
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.
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).
is it? that would pretty much make GTA a non-issue if they all said that it was going to be returned.
Re: Sidechannel pixel-stealing attack works in Chromium on all modern GPUs
#28Earlier quoted context omitted.
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.
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.
Re: Sidechannel pixel-stealing attack works in Chromium on all modern GPUs
#29This 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 banki…
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?
Re: Sidechannel pixel-stealing attack works in Chromium on all modern GPUs
#30This 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 banki…
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