41–50 of 71 posts
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.
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.
Preprint paper: https://www.hertzbleed.com/gpu.zip/GPU-zip.pdf
Earlier quoted context omitted.
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
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?
But is it really stealing if the owner isn't deprived of use? It's just costless duplication of a nonscarce resource.
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.
Piracy is the odd-one-out because it's about "stealing" non-secret information, which seems non-sensical.
But is it really stealing if the owner isn't deprived of use? It's just costless duplication of a nonscarce resource.
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.
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.
Earlier quoted context omitted.
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
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?
Earlier quoted context omitted.
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
Earlier 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).
Earlier quoted context omitted.
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 coul…
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.
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 banki…
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?