14 ms·
Sidechannel pixel-stealing attack works in Chromium on all modern GPUs
- anfilt 3y agoThe 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 3y agoYes, 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 3y agoIn 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 3y agoI mean, Google keeps packing more and more weird nonsense features into Chrome (e.g. https://support.google.com/chrome/answer/6362090?hl=en&co=GENIE.Platform%3DDesktop https://support.google.com/chrome/answer/6362090?hl=en&co=GE...) so uh...
- djbusby 3y agoSeems like the root reason for wanting accelerated CSS on cross-origin iframe is for flashy/fancy embeds...like, IDK, ads or something?
- kevingadd 3y agoAt 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.
- vimax 3y agoYou 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 3y agoInteresting 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 3y agoYes, 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 3y agoI 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.
- tedunangst 3y agoBut is it really stealing if the owner isn't deprived of use? It's just costless duplication of a nonscarce resource.
- mmastrac 3y agoI 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.
- andyferris 3y agoI 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.
- j16sdiz 3y ago"Stealing" non-secret information is like "stealing" toilet paper from public toilets.
- skybrian 3y agoIt'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.
- hn_acker 3y agoActually, 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.
- 3y ago
- pests 3y agoPixel 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.
- pshc 3y agoCould we, like, do away with iframes?
- bradleybuda 3y agoPortals were (are?) an attempt to do this. Haven't heard much about them in a while: https://github.com/WICG/portals#summary-of-differences-between-portals-and-iframes https://github.com/WICG/portals#summary-of-differences-betwe...
- bqmjjx0kac 3y agoPlease delete JavaScript while we're at it.
- mjevans 3y agoJavaScript 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.
- jefftk 3y agoDo away with iFrames and we'll have ads running same-origin to content. So much XSS...
- asddubs 3y agoit would be enough to disallow/containerize third party cookies, like pretty much every browser besides chrome does
- baz00 3y agoWe should have never gone past Gopher :)
- AlexCoventry 3y agoWhat is it with these strangers who want to run stuff on my computer without my explicit permission?? :-)
- baz00 3y agoExactly! If I want to run something on my computer I’ll damn well download a tar file and spend several hours arguing with autoconf! :)
- quickthrower2 3y agoDefine run
- deleted 3y ago[deleted]
- Dwedit 3y agouMatrix-like extensions will stop this, making you explicitly allow the iFrame to run before it can happen.
- Ygg2 3y agoBefore Chrome cripples uMatrix for "security reasons".
- stuaxo 3y agoHas 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.
- vacuity 3y agoTime 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.
- josefx 3y ago> Time to write a comprehensive paper titled "Optimizations Considered Harmful". Apparently the other browsers went with "don't inject untrusted third party code into a site".
- chromoblob 3y agoProblem is not in optimization but in leaking time.
- treyd 3y agoThe problem really seems to be with running arbitrary untrusted code.
- vessenes 3y agoThis 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 3y agoI love 3d graphics on the web but man it seems to be an infinite security hole
- kevingadd 3y agoIn 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
- chatmasta 3y agoTechnically 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?
- zorgmonkey 3y agoPoC code: https://github.com/UT-Security/gpu-zip https://github.com/UT-Security/gpu-zip Preprint paper: https://www.hertzbleed.com/gpu.zip/GPU-zip.pdf https://www.hertzbleed.com/gpu.zip/GPU-zip.pdf
- hakre 3y agoIsn't using GPU and hardware acceleration considered experimental in browsers and the safe default to disable such features for day-to-day use? Not saying to make this achievement smaller than it is, quite the opposite, it's important there is more such research.
- jethack 3y agoNo, these features have been enabled by default for a decade+ on every platform that isn't desktop Linux, including such modern browsers as IE9
- chromoblob 3y agoVery good. A step towards the proper concept of computer security.
- quinncom 3y agoUntil Google decides whether and how to patch, it seems blocking all third-party iframes can mitigate this issue, using this uBlock Origin rule: ||*^$subdocument,third-party