[HN Gopher] Sidechannel pixel-stealing attack works in Chromium ...
___________________________________________________________________
Sidechannel pixel-stealing attack works in Chromium on all modern
GPUs
Author : anfilt
Score : 96 points
Date : 2023-09-26 17:52 UTC (5 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| pshc wrote:
| Could we, like, do away with iframes?
| bradleybuda wrote:
| 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...
| bqmjjx0kac wrote:
| Please delete JavaScript while we're at it.
| tedunangst wrote:
| But is it really stealing if the owner isn't deprived of use?
| It's just costless duplication of a nonscarce resource.
| kube-system wrote:
| 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.
| danielheath wrote:
| 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).
| dylan604 wrote:
| is it? that would pretty much make GTA a non-issue if they
| all said that it was going to be returned.
| codetrotter wrote:
| Analogies never work.
|
| 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.
|
| - etc
| skybrian wrote:
| It's a bit odd to think of a password as a "non-scarce
| resource" when they protect scarce resources.
|
| I expect they're not often visible, though.
| giantrobot wrote:
| Someone stealing my password can go hunter2ing their hunter2 in
| their hunter2.
| cosmotic wrote:
| It takes ~1hour to grab an unspecified portion of the screen
| (screenshots show a tiny 100x100 or so box). I'd say not
| costless.
| mmastrac wrote:
| 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.
| ftxbro wrote:
| You wouldn't download a car.
| baz00 wrote:
| We should have never gone past Gopher :)
| AlexCoventry wrote:
| What is it with these strangers who want to run stuff on my
| computer without my explicit permission?? :-)
| stuaxo wrote:
| Has 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.
| [deleted]
| vessenes wrote:
| 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!
| kfarr wrote:
| I love 3d graphics on the web but man it seems to be an
| infinite security hole
| kevingadd wrote:
| 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
| twelvechairs wrote:
| 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?
| kevingadd wrote:
| disabling CSS/SVG filters for cross-site content also seems
| like a pretty reasonable thing to do
| anfilt wrote:
| 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.
| stalfosknight wrote:
| 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.
| kevingadd wrote:
| 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.
| ForHackernews wrote:
| I mean, Google keeps packing more and more weird nonsense
| features into Chrome (e.g. https://support.google.com/chrom
| e/answer/6362090?hl=en&co=GE...) so uh...
| vimax wrote:
| 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.
| beebeepka wrote:
| 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
| kevingadd wrote:
| 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.
| kevingadd wrote:
| 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.
| djbusby wrote:
| Seems like the root reason for wanting accelerated CSS on
| cross-origin iframe is for flashy/fancy embeds...like, IDK,
| ads or something?
| kevingadd wrote:
| 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.
| pests wrote:
| Pixel by pixel.
|
| > 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.
| Dwedit wrote:
| uMatrix-like extensions will stop this, making you explicitly
| allow the iFrame to run before it can happen.
___________________________________________________________________
(page generated 2023-09-26 23:00 UTC)