Weekly Edition
Return to the Security page
| |||||||||||||
Jacob: Cross-domain WebGL textures disabled in Firefox 5
Over at hacks.mozilla.org, Benoit Jacob explains why cross-domain textures have been disabled for WebGL in Firefox 5. "When a cross-domain image was used as a WebGL texture, the WebGL canvas was "tainted" so that reading from it was no longer possible. Theoretically, that eliminated the concern. But a while ago, a researcher wrote to the public WebGL list with a possible attack that could still allow reading pixels from WebGL textures. The idea was to paint the texture one pixel at a time with a WebGL fragment shader crafted to take an amount of time proportional to its brightness, and then time how long it takes: that would conceivably allow to get an approximation of the original image. Initially this attack seemed difficult to execute practically, but since then further research, including a proof-of-concept has been published which shows the attack to be more realistic than initially expected." LWN looked at WebGL vulnerabilities a few weeks back.
(Log in to post comments)
Jacob: Cross-domain WebGL textures disabled in Firefox 5 Posted Jun 10, 2011 6:49 UTC (Fri) by Cato (subscriber, #7643) [Link]
The latest NoScript for Firefox blocks WebGL for untrusted sites: http://noscript.net/
NoScript Posted Jun 10, 2011 9:49 UTC (Fri) by josh (subscriber, #17465) [Link]
Separately from its blocking of JavaScript? If you don't trust a site to run WebGL, why would you trust it to run JavaScript at all, given the premise of NoScript that JavaScript should only run on trusted sites?
NoScript Posted Jun 10, 2011 11:27 UTC (Fri) by Cato (subscriber, #7643) [Link]
There is a specific WebGL block, like the way NoScript blocks Java or Flash. See http://noscript.net/changelog and search for WebGL. Probably a belt and braces thing: if you block WebGL and JS, then even if you accidentally allow all JS on a site you are still safe against WebGL exploits. JS generally seems safer than JS+WebGL, given the novelty of potentially web-exploitable GPUs.
Jacob: Cross-domain WebGL textures disabled in Firefox 5 Posted Jun 10, 2011 21:38 UTC (Fri) by jpnp (subscriber, #63341) [Link]
Thankfully, Mozilla have always protected me from WebGL vulnerabilities: WebGL is blacklisted on all five Linux desktops I make use of.
Jacob: Cross-domain WebGL textures disabled in Firefox 5 Posted Jun 11, 2011 3:21 UTC (Sat) by bjacob (subscriber, #58566) [Link]
Jacob: Cross-domain WebGL textures disabled in Firefox 5 Posted Jun 13, 2011 3:34 UTC (Mon) by Hausvib6 (guest, #70606) [Link]
So... in English, what kind of attack can happen to the WebGL-enabled browser user?
Jacob: Cross-domain WebGL textures disabled in Firefox 5 Posted Jun 13, 2011 6:42 UTC (Mon) by tetromino (subscriber, #33846) [Link]
Alice and Eve play on opposite sides in an online game written in WebGL. Eve notices a way to trick the game into embedding resources from external websites into the in-game chat. She sends Alice a chat message that loads a malicious shader on Alice's client. As soon as Alice's client renders the message, the shader dumps the client image data to Eve's website. Eve sees what items Alice has in her inventory, and gains an unfair advantage.
Jacob: Cross-domain WebGL textures disabled in Firefox 5 Posted Jun 13, 2011 9:33 UTC (Mon) by elanthis (guest, #6227) [Link]
more likely occurrance:
It's impossible to stop clients from _easily_ inspecting and modifying the code, even with JS obfuscators. Eve just modifies her copy of the client to make nearby walls slightly transparent, or send fradulent "got item X" messages in the peer-to-peer network setup necessary for many types of action games, or inserts an aim-bot, or does any of a ton of other possible client-side cheats.
In most networked games, getting the other player's textures (especially using a slow HTML/HTTP-friendly method) isn't anywhere remotely near as interesting as just modifying the client source code.
It's simply not possible to implement fast-paced games using a complete server-side-only game logic setup due to the realities of modern network latencies. Even if we could have that, hacking the rendering code would still make many kinds of cheats possible. Think of a game where camo works by making you blend into the environment and be hard to notice (like the Call of Duty games does, in fact); hack the character models so all enemies are bright orange and bam, you've got a powerful cheat. Or think of games with lots of foliage for cover; disable rendering of those and you can see just about everything. Same goes for just making most occluding terrain partially transparent, or even just adding a HUD displaying locations of nearby enemies that the server has to assume the client can _maybe_ see but the actual rendering might occlude.
There's a reason that players often _want_ DRM-like systems for multiplayer games. It curtails cheating for at least a few months during the game's initial release when people are playing it most often.
Jacob: Cross-domain WebGL textures disabled in Firefox 5 Posted Jun 16, 2011 14:58 UTC (Thu) by Kwi (subscriber, #59584) [Link] A shader that performs network communication? No, that's not the issue. The issue is this: On my personal webserver, I've put up an image that I don't want anyone to see without my permission. Hence I've placed it on the private part of my website, which is password-protected (http://private.example.com/noodle-incident.jpeg). Having previously logged in to the private part of my website (for some reason or other), I now visit the website of Eve (http://evil.example.org/). Imagine that Eve has learned the noodle-incident URL, and wants to see the photo. Eve can simply include the photo on evil.example.org using <img src="http://private.example.com/noodle-incident.jpeg" /> but it'll only show up in my browser. Everyone else will get a broken image. Now, Eve can add JavaScript to evil.example.org, and that code will run in my browser, with my access. She might then try to read the pixel values off the <img /> as it's shown in my browser, but that will fail, because the image data is cross-domain tainted and thus inaccessible to JavaScript. Similarly, she might render the image to a WebGL canvas. This will just result in the WebGL canvas becoming tainted as well, so she hasn't gained anything. But once she adds her own evil shader, she can use the described timing attack to grab pixel values, even though all pixel data is tainted and thus inaccessible to scripts.
Jacob: Cross-domain WebGL textures disabled in Firefox 5 Posted Jun 17, 2011 19:37 UTC (Fri) by raven667 (subscriber, #5198) [Link]
I don't claim to understand the attack but would that work only for files that look like valid image data or any binary data?
This whole WebGL thing seems like a fundamentally bad idea, even Microsoft doesn't want to touch it with a 10-ft borrowed pole due to the security implications
Jacob: Cross-domain WebGL textures disabled in Firefox 5 Posted Jun 18, 2011 17:53 UTC (Sat) by Kwi (subscriber, #59584) [Link]
This particular exploit would only work for actual valid image data. (The image must be renderable.)
As for the general security of WebGL, there's no reason why it shouldn't be secure, except that the technology is new and untested.
The fundamental problem (which has nothing to do with WebGL) is that browsers still run different websites in the same security context. Various work-arounds (cross-site checks) have been added over the years, but the fundamental flaw remains unfixed, since fixing it would break backwards compatibility.
Jacob: Cross-domain WebGL textures disabled in Firefox 5 Posted Jun 19, 2011 14:49 UTC (Sun) by job (guest, #670) [Link]
Interestingly enough, Microsoft implements something similar but incompatible in the coming version of their Silverlight plugin.
Worst case scenario perhaps Posted Jun 19, 2011 14:56 UTC (Sun) by job (guest, #670) [Link]
Considering the state of most 3D graphics drivers, I wouldn't be surprised of shader consists of a blob with illegal instructions and binary noise which you suddenly found DMA'd right in front of your code pointer.
I know nothing about shaders,so please don't take my word that this scenario is even possible, but I personally wouldn't want to use it until some security minded people had a long, hard look at it instead of the happy web people where it originated.
Worst case scenario perhaps Posted Jun 19, 2011 15:05 UTC (Sun) by bjacob (subscriber, #58566) [Link]
Shaders are validated by the ANGLE shader compiler before being passed on to the GPU driver, so what you describe can't happen.
Worst case scenario perhaps Posted Jun 21, 2011 10:39 UTC (Tue) by job (guest, #670) [Link]
I'm not entirely convinced this would protect against buggy OpenGL drivers, but I would be happy to be wrong.
Let me put it this way: There is a risk that WebGL could turn a local OpenGL call exploit to a remote one.
|
|||||||||||||