Jacob: Cross-domain WebGL textures disabled 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.
Posted Jun 10, 2011 6:49 UTC (Fri)
by Cato (guest, #7643)
[Link] (2 responses)
Posted Jun 10, 2011 9:49 UTC (Fri)
by josh (subscriber, #17465)
[Link] (1 responses)
Posted Jun 10, 2011 11:27 UTC (Fri)
by Cato (guest, #7643)
[Link]
Posted Jun 10, 2011 21:38 UTC (Fri)
by jpnp (guest, #63341)
[Link] (1 responses)
Posted Jun 11, 2011 3:21 UTC (Sat)
by bjacob (guest, #58566)
[Link]
Posted Jun 13, 2011 3:34 UTC (Mon)
by Hausvib6 (guest, #70606)
[Link] (9 responses)
Posted Jun 13, 2011 6:42 UTC (Mon)
by tetromino (guest, #33846)
[Link] (8 responses)
Posted Jun 13, 2011 9:33 UTC (Mon)
by elanthis (guest, #6227)
[Link]
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.
Posted Jun 16, 2011 14:58 UTC (Thu)
by Kwi (subscriber, #59584)
[Link] (6 responses)
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 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.
Posted Jun 17, 2011 19:37 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (2 responses)
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
Posted Jun 18, 2011 17:53 UTC (Sat)
by Kwi (subscriber, #59584)
[Link]
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.
Posted Jun 19, 2011 14:49 UTC (Sun)
by job (guest, #670)
[Link]
Posted Jun 19, 2011 14:56 UTC (Sun)
by job (guest, #670)
[Link] (2 responses)
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.
Posted Jun 19, 2011 15:05 UTC (Sun)
by bjacob (guest, #58566)
[Link] (1 responses)
Posted Jun 21, 2011 10:39 UTC (Tue)
by job (guest, #670)
[Link]
Let me put it this way: There is a risk that WebGL could turn a local OpenGL call exploit to a remote one.
Jacob: Cross-domain WebGL textures disabled in Firefox 5
NoScript
NoScript
Jacob: Cross-domain WebGL textures disabled in Firefox 5
Jacob: Cross-domain WebGL textures disabled in Firefox 5
Jacob: Cross-domain WebGL textures disabled in Firefox 5
Jacob: Cross-domain WebGL textures disabled in Firefox 5
Jacob: Cross-domain WebGL textures disabled in Firefox 5
Jacob: Cross-domain WebGL textures disabled in Firefox 5
<img src="http://private.example.com/noodle-incident.jpeg" />
Jacob: Cross-domain WebGL textures disabled in Firefox 5
Jacob: Cross-domain WebGL textures disabled in Firefox 5
Jacob: Cross-domain WebGL textures disabled in Firefox 5
Worst case scenario perhaps
Worst case scenario perhaps
Worst case scenario perhaps