James Forshaw - 11th May 2011
Due to the high level of interest in Context’s blog posting on the Security issues within WebGL we are releasing the following further information to aid in the understanding of the issues.
“Am I vulnerable to WebGL based attacks?”
This depends on the browser you are using, operating system and graphics card. Use this test page to determine if you have WebGL support and are therefore exposed. WebGL is currently supported on Firefox and Chrome web browsers; if you are using Internet Explorer, Safari or Opera (at the time of writing) you are not vulnerable to WebGL issues.
“How can we be safe from WebGL based attacks?”
Context recommend that users disable WebGL support from within their web browsers in the short term (see below).
However in the longer term, Context believes that browser vendors should, by default, disable WebGL from within their web browsers. We would like to see functionality included that would allow users to opt-in for WebGL applications that they trust on a case by case basis.
“You said we should consider disabling WebGL, how exactly would you go about doing that?”
- Type into the URL bar “about:config” and click the “I’ll be careful” button.
- Find the setting “webgl.disabled” and set it to true as show in the following picture:
- For Chrome on Windows pass the flag “--disable-webgl” when running the executable by changing the shortcut in the start menu. A user can right click on the chome shortcut, select properties and add the flag as per the following screenshot.
- For Chome on OSX the parameter “—disable-webgl” needs to be added on startup. See the following article for details on adding parameters for chrome. http://superuser.com/questions/271678/how-do-i-pass-command-line-arguments-to-dock-items
- Unless you are using a nightly builds of WebKit WebGL is not easily available and requires a user preference setting to enable. Therefore you do not need to actively disable it at the moment.
“No Script Provides WebGL Security for Firefox”
Context has been working with the developers of the Firefox plug-in NoScript (http://noscript.net/) to include support to allow users to selectively disable WebGL. Context recommends this plug-in to protect users from malicious content from the Internet.
“Would the use of the GL_ARB_robustness extension eliminate the Denial of Service issues with WebGL?”
Khronos (the authors of the WebGL specification) released a blog posting on 9th May 2010 detailing certain security mechanisms that enhance the security of WebGL http://www.khronos.org/news/permalink/webgl-security. One of the theoretical solutions suggested is the use of GL_ARB_robustness which is an extension that graphic card manufacturers can provide to detect the Denial of Service issue that we detailed in our original Blog. Based on the current information available it seems that it would at least mitigate the direct DoS condition where the whole machine becomes unresponsive or crashes. It puts the onus on the Graphics Hardware manufacturer to develop a mechanism to detect a lock up condition and reset the device, the extension then really provides a way for clients to recognise compatible configurations.
However we do not believe it addresses the wider issue. The resetting of the graphics card and driver should be seen as a crutch to OS stability when exceptional conditions occur and not as a mechanism to protect users from malicious code. Resetting the graphics card isn’t guaranteed to be a trouble free operation; all other users of the graphics subsystem will need to correctly handle the event. The graphics stack would have to ensure that any hardware resources are recreated before use to guard against another application misusing it. This operation, while not causing a DoS directly, could still indirectly effect the entire system and the applications running on it.
Perhaps the closest analogy would be to consider a hard drive which could be locked up when someone issued a malicious Write command. Rather than stopping malicious code from issuing these “bad” writes, instead the manufacturer just allows the hard disk to be reset, making everyone’s state inconsistent from the file system layer to user mode processes. That does not seem a great way of fixing it.
“The proof of concept does not seem to work correctly; is WebGL not supported on Nvidia/ATI/Intel graphics cards?”
In theory any graphics card capable of supporting OpenGL (or DirectX on Windows) should work with WebGL. However the browsers have a blacklist of graphic drivers where significant issues have been encountered and will block WebGL use. Therefore normally the way to get WebGL support is to update to the latest drivers for your graphics card however not all hardware has compatible drivers. Where a driver is blacklisted by the browser it is still possible for a user to override this check, however this is not recommended.
“Is there a way of blocking the cross-domain image issue without removing support for cross-domain textures or imposing CORS?”
There would almost certainly be ways of doing it; however it would likely cause significant issues to the usability of any platform which tried. For example the shaders could be prevented from accessing texture data completely; this would seem somewhat overkill and remove most of the benefits of the programming model. You also cannot just eliminate loop constructs in the shaders; the render time is directly related to how many pixels you need to draw, therefore one trick would be to scale a polygon relative to the brightness of a pixel you want to read, that would increase the number of times the fragment shader is executed which would produce a measurable time difference. Therefore Context would recommend the use of a mechanism to manage cross-domain images for example the requirement of CORS within WebGL.
“What responses have you had from the Browser vendors?"
Context has reported these issues and other vulnerabilities to the Mozilla Security group who has raised a number of internal bug reports regarding the issues that we have found, including issues that we have not publicly disclosed. They have also passed the information onto Google for Chrome. The Mozilla Security Group has been very receptive to the issues that we have raised and have been very responsive to our concerns. They have also passed the information onto Google for Chrome.