WebGL & Security

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.

This entry was posted in Free Software and tagged , . Bookmark the permalink.

14 Responses to WebGL & Security

  1. Danny Moules says:

    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.

  2. Danny Moules says:

    “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.

  3. Yuri Leven says:

    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

  4. Np237 says:

    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.

    • Benoit Jacob says:

      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.

  5. Benoit Jacob says:

    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.

  6. Yuri Leven says:

    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.

    • Benoit Jacob says:

      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.

  7. foo says:

    I for one will be disabling WebGL just like I’ve disabled web fonts.

    • Benoit Jacob says:

      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.

  8. fsync says:

    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.

  9. Pingback: WebGL considered harmful | Scali's blog

  10. Pingback: Has HTML5 made us more secure?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s