WebGL Poses New Security Problems

Julie188 writes "Researchers are warning that the WebGL standard undermines existing operating system security protections and offers up new attack surfaces. To enable rendering of demanding 3D animations, WebGL allows web sites to execute shader code directly on a system's graphics card. This can allow an attacker to exploit security vulnerabilities in the graphics card driver and even inject malicious code onto the system."

Glad I'm not using Binary Blob drivers

[xiando]

An attack based on "exploit security vulnerabilities in the graphics card driver" seems less likely using the FOSS graphics drivers. I'm not saying they can not be exploited, I'm just saying that this makes me feel somewhat safer than I would feel if I were using the closed Binary Blob drivers.

Quake Live

[mfh]

I raised this concern with Quake Live, but was quickly shut down by people. Nobody wants to listen to the possible security holes in something they want to ram through at all cost. Forgive my tone if I'm a little annoyed hearing this. Sometimes you want to be wrong about something, but now I have been proven correct, I'm annoyed with myself.

Misleading

[Eravnrekaree]

This is overstated and inaccurate headline. A large area of harm can come from a software application accessing memory space which is a hardware adapter mapped into address space of the app, and manipulation of pointers and so on. This is a issue with C level programming where you have direct access to memory addresses and pointers. A javascript implementation of WebGL does not offer access to OpenGL functions by addresses or pointers to the functions at all. Instead it should use a dispatch table below the javascript environment. JS is thus isolated from direct access to hardware and IS NOT using hardware addresses in any way to access functions.The WebGL program can only therefore access the functions via that dispatch table. There are still possible issued with problems with the OpenGL API itself that may need to be addressed for safety. However, direct access to video hardware by a Javascript app is out of the question, it should not be done, and should not be allowed in a Javascript environment. the Javascript is a sandbox and does not provide direct access to memory address space, system calls or other such things. if security is a concern, due to Hardware faults that could be triggered by sending a series of OpenGL commands, the web browser can be configured to use software renderer instead of the hardware rendering, or selectively block that series of OpenGL commands in some way. If there are significant problems with hardware rendering, that may be sometjhing that may have to be considered as a default option. this is something that can affect all applications that are used over a network including gaming applications, since, even a gaming app that sends abstracted updates such as "soldier moves forward 200px" can trigger OpenGL calls in a predictable way. However, these nor WebGL should not expose the graphics hardware directly to Javascript or the network protocol, nor the address space, only OpenGL functions can be called by some sort of token or symbol which is contained within the sandbox environment and does not directly referfence a memory location. Those OpenGL functions are used by a wide range of different network applications, so this is not a problem particular to WebGL.

I am a web rendering engine developer so I have an interest in making sure these things are safe. If necessary we will software render by default until we can be sure about safety with direct rendering. Furthermore this is not a WebGL problem,s, these are bugs in OpenGL itself. There are software rendering workarounds. So this will not affect the availability of WebGL.

I do support WebGL since it will help the web environment compete against Flash.