Comments on

Trapped in WebGL

Original entry posted: Fri Dec 9 20:31:15 2011

Johann @ Sat Feb 4 10:39:37 2012 EST

oh come on.. I know the learning curve is steep.. I am just now learning it myself, and it will take more than this weekend to get my very basic particle/camera system up and running in shaders, (not to mention it being actually decent, and not just somewhat working haha)... but at the same time, how would you suggest enabling such raw power via easy wrappers? I seriously wonder.

Also, screw what Microsoft thinks -- what are *they* suggesting? "let's not allow modern gfx because it's hard and we haven't thought about security in that area yet"? No wait, they are probably suggesting Silverlight. Heh. Clowns. But I guess that whole are of the argument would be lost on you anyway so hey. Screw DirectX as well. If it's so great, let Microsoft make it an open standard, until then it does not exist. Kthxbye.

And what are you talking about with this statement

"web developers write and deliver code that is compiled and run directly on the graphics card to handle scene transformation and rendering. That's pretty low-level access to memory, being granted to arbitrary people on the Internet, with security only as strong as your video driver"


Yes, that code is compiled and "run directly" on the GPU, but there isn't really any access to memory. The shader can setup it's own variables and doesn't see anything else -- whoop-dee-doo?? The only things it can write is gl_position or gl_fragcolor. What an attack surface. Maybe I'm missing something, I'm hardly a pro with all this; but by your own admission, neither are you. So, can you back up the above with anything, or did you just make it up?

But sure enough, just when trying to learn this stuff, I managed to crash my GFX card driver and got a blue screen (something some games, or even media players, have NO problem pulling off, by the way - my card may simply suck). But if "loosing unsaved documents" is the peak of the security threat here, I'd call it survival of the fittest and overall a huge payoff for little cost.

Thomas @ Fri Feb 10 14:32:47 2012 EST

I think given the examples of Three.js and Stage3D, it shouldn't be a difficult exercise to imagine a less clumsy, JavaScript-native API than WebGL.

I'm hardly making up the serious security issues here. Think about what you just wrote: messing around with shaders, you were able to blue-screen your computer. Any security researcher will tell you that a crash is the first step to a security vulnerability. If you can use it to trigger a buffer overflow, or to jump to a given location in memory (maybe one that contains with native code written via a GL buffer), the computer stands to lose a lot more than just your unsaved documents.

People have been exploiting security features in "managed" ActionScript for years now. There have been spray attacks using nothing more than the JavaScript JIT in modern browsers. And you're not concerned about giving people access to the kernel through your video driver? Well, you're braver than I am, to put it kindly.

How we solve that, and grant these capabilities to web apps, I don't know. But "survival of the fittest" is not a valid response when it comes to security.

Pollxn Discussion Engine