Recently Context Information Security Limited gathered a lot of attention for a blog post on the state of WebGL security. For Mozilla, WebGL was first released in Firefox 4, and there are implementations in Chrome, Safari and Opera as well. The blog post outlines an abstract concern that WebGL is inherently insecure because it allows fairly direct access to the hardware, along with two specific attacks, a Denial of Service and a Cross-Domain Image Theft.
The Denial of Service attack does not generally endanger user data or privacy, but it can be highly annoying for users, not unlike sites that pop up multiple dialogs or have long-running javascript that hangs the browser. The Khronos WebGL working group has been aware of this type of issue for some time and has discussed it openly. Shader validation can help somewhat, as can GL_ARB_robustness, but the forthcoming GL_ARB_robustness_2 extension will help even more. There are also user confirmation approaches available as well depending on what real world data we uncover over time.
The Cross-Domain Image Theft issue is indeed a viable attack. It had been previously theorized, but no known proof of concept giving meaningful results existed until now. While it is not immediately obvious that it can be exploited in a practical attack right now,
experience in security shows that this is a matter of when, not if. Mozilla is engaged with browser, OS and hardware vendors in the WebGL mailing list to solve this as quickly as possible. One solution is simply to disallow the use of cross-domain images that do not have CORS approval in the WebGL context, which currently is Mozilla’s preferred solution. Mozilla is committed to rolling out a solution that secures against real threats while keeping WebGL a viable platform.
The abstract concern around hardware access is something we (and other browser vendors) have thought about a lot during design and implementation. For Firefox we first addressed this by employing both a whitelist and a blacklist for drivers. The blacklist can be deployed daily without a full software update so we can respond rapidly to any issues. We’ve also been working with driver vendors, both before and after the release, through the Khronos WebGL working group to report and solve specific issues. Vendors must be active in order to be whitelisted. Longer term, again through Khronos, we continuously work to raise overall vendor awareness and develop more advanced counter measures such as the openGL GL_ARB_robustness_2 extension to mitigate various types of attacks.
WebGL is a powerful technology and we certainly recognize that significant attacks against it may be possible. Nevertheless, claims of kernel level hardware access via WebGL are speculative at best since WebGL shaders run on the GPU and shader compilers run in user mode. We’re keen to work with Context, or any other group, on identifying and
closing specific, concrete attacks as they emerge.
What poor research. Lots of assertions and lots of mendacious accusations.
“Based on this limited research Context does not believe WebGL is really ready for mass usage, therefore Context recommends that users and corporate IT managers consider disabling WebGL in their web browsers.”
‘Limited research’ is generous. I’ve seen all these points being discussed in the WebGL design and implementation process. To then make recommendations based on these ‘revelations’, without any peer review, is just terrible science.
I can imagine why they post these in their blog instead of publishing their research as a peer-reviewed paper.
“the way in which WebGL has been specified insufficiently takes into account the infrastructure required to support it securely. This is evident from the development of ways to mitigate the underlying security issues by introducing validation layers and driver black-lists;”
So the fact that they took into account the infrastructure required to support it securely is proof that they didn’t take into account the infrastructure required to support it securely? Um. Quite.
“At this point it would seem to be reasonable to provide a proof of concept; however Context did not need to even write one as Khronos provides one in their WebGL SDK.”
I think this line sums up everything.
JP – this is excellent news. What % of gpus have the arb1 protection today? How can I tell if I am safe or whether I should for now?
Yuri
Does WebGL make use of GLX for display on Linux machines?
I’m asking, because GLX is well-known for being very badly designed, with a shitload of root security holes waiting to be found. Please don’t make them remote root issues.
Np237: We do use GLX on Linux. However the WebGL implementation only uses it during initialization to create a OpenGL context. GLX isn’t exposed to input from content, besides the WebGL context creation options (which is… less than 1 byte of data!). So I don’t see a risk here. In the long term, it’s very possible that EGL replaces GLX.
Yuri: As far as I know, ARB_robustness is more a driver feature than a hardware GPU feature. I’m not sure about the percentage, but recent versions of NVIDIA and ATI OpenGL drivers have it, I think. Not sure about Intel. You can check that using any OpenGL info utility, see if the “GL extensions string” contains ARB_robustness.
You don’t have to do anything to be decently safe. It’s our job to ensure that Firefox with the default settings is a safe browser. We’re working on any real issues (especially the cross-domain image issue) as hard as we can, but they’re not looking severe enough at this point in the real world to require an immediate update.
Thanks Benoit.
My Mac is about two years old. I ran the link from Engadget and Chrome froze. I didnt want to do the test in Firefox. I posted a message to Apple support and have not gotten a response.
So I think I have the graphics problem. What do you recommend? I am going to the genius bar tomorrow to ask their advice.
Yuri: on Mac, Apple controls the whole graphics stack including the drivers. It’s up to them to implement ARB_robustness; I believe that is not yet implemented. Regarding the freezes on Mac in certain heavy WebGL demos, I’m aware of the problem but I don’t have much advice at the moment, sorry. If the issue gets really bad, we might end up making ARB_robustness a requirement for WebGL.
I for one will be disabling WebGL just like I’ve disabled web fonts.
To put Context’s affirmation into some perspective, here is the list of top 300 crashers in Firefox 4:
https://crash-stats.mozilla.com/topcrasher/byversion/Firefox/4.0.1
As you can see, WebGL doesn’t even show up on this list. I’m not sure how much further down the crashers list one would have to look to start seeing a lot of WebGL crashes.
Of course the DOS problem with WebGL is not only about process crashes, but you get the picture: disabling WebGL is not, in general, going to significantly improve user experience. YMMV.
How does it work to have both a blacklist and a whitelist? I’m guessing this refers to what is known about drivers (known good, known bad, or not sure) rather than a policy implemented in code to decide whether to allow features to execute with certain drivers.
The difference between a whitelist and a blacklist is a little abstract given that we have rather complex logic here. It’s very OS-specific, but for example on Windows we have a whitelist of vendors (with only ATI/AMD, NVIDIA and Intel on it at the moment) and then we have a blacklist of combinations of driver versions, devices and requested features. Details are given on this wiki page:
https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers
Pingback: WebGL considered harmful | Scali's blog