WebGL vulnerabilities

A recent report that highlighted some potential and actual security vulnerabilities in WebGL has been widely circulated. It should probably not come as a surprise that a new whiz-bang feature that is meant to allow web content to interact with complex 3D graphics hardware might lead to problems. Since it is all-but-certain that browser makers will be enabling—in many cases already have enabled—this feature, it will be interesting to see how the security holes will be filled as they make their way from theoretical to actual vulnerabilities.

WebGL is a low-level 3D graphics API that is based on the OpenGL ES 2.0 standard implemented by libraries for most fairly recent 3D graphics cards. For browsers with WebGL support, the HTML canvas element can be used to display accelerated graphics in the browser that can be controlled via JavaScript. For gaming, exploring 3D landscapes, undoubtedly annoying advertisements, and plenty of other uses, WebGL will be a welcome addition to web browsers. But allowing arbitrary content flowing across the internet to interact with complex hardware certainly seems like it might lead to security problems.

Graphics hardware typically consists of one or more graphics processing units (GPUs) that are accessed through a driver. The driver provides some standardized interface to higher-level libraries that implement a graphics standard like OpenGL. But, in order to provide the most flexibility for graphics programmers, much of what gets handed off to the libraries are special-purpose programs called shaders. Shaders are written to handle the complexities of the graphics to be rendered, and the libraries and drivers turn those programs into the proper form for the GPU(s) in the hardware.

Essentially it means that malicious web sites can craft semi-arbitrary programs to run on the hardware of the user. That alone should be enough to give one pause from a security perspective. One obvious outcome is that malicious shaders could be written to essentially monopolize the graphics hardware, to the detriment of anything else that's trying to write to the display (e.g. other windows). In the worst case, it could lead to the user having to reinitialize the graphics hardware—possibly requiring a reboot.

That kind of denial of service could be extremely annoying to users, but doesn't really directly impact the security of the desktop. It would not leak user data to the malicious site, though it could potentially result in data loss depending on what else the user was doing at the time. It is, in some ways, similar to the problems of malicious, infinitely looping JavaScript, which can lock up a browser (but not generally the whole desktop). Running browser tabs as separate processes, as Chromium does and Firefox is moving to, also mitigates the JavaScript problem to a large extent.

But that's not the only problem that the report from Context, a UK-based security consulting company, outlined. Another potential attack is a cross-domain image theft. When canvas elements include cross-domain content, say an image from another site, there is a "origin-clean" flag that gets cleared in the browser which disables some of the JavaScript functions that might be used to extract the, potentially sensitive, image data from the other domain. However, a malicious canvas element could create shaders that will effectively leak the image contents.

The attack relies on a technique long-used to extract cryptographic keys by doing a timing analysis. If shaders were written to take longer based on the "brightness" of a pixel, JavaScript could be used to regenerate the image based on how long each pixel takes to render. It is a complicated attack to do, and finding real-world exploits using it may be somewhat convoluted, but it is a cross-domain vulnerability. An example that Context gives is a victim site that puts up a specific profile image based on the session information stored in a browser cookie for the site, which gets sent to the site as part of the request for the image. The malicious site that included the victim image couldn't get at the cookie, but could infer the logged-in user by comparing the displayed image to a list of known "interesting" profile images.

Mozilla hacker JP Rosevear responded to Context's report noting that the cross-domain image theft problem is real, even though it may be difficult to exploit in practice: "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." His suggested fix is the cross-origin resource sharing (CORS) proposal that would allow sites to explicitly list which other sites can include their content.

The denial of service problem is harder, though. The only real defense against maliciously written shaders is to validate that code in ways that, hopefully, eliminates bad shaders. That, of course, is something of an arms race, so Rosevear also suggests that some kind of user confirmation before displaying WebGL content may be required.

There are also some efforts afoot to try to handle denial of service issues in the hardware itself. GL_ARB_robustness (and GL_ARB_robustness_2) are mechanisms that the hardware makers can use to detect these kinds of problems and reset the hardware when they occur. As Context's FAQ indicates, though, that may not be real solution in the long term:

From a security standpoint, allowing any random web site to send code that is more-or-less directly executed on system hardware is always going to be somewhat problematic. Rosevear points out that there is separation between the components of WebGL that should provide some isolation: "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." That assumes that the libraries and drivers don't have exploitable bugs of their own, of course. As Rosevear notes, "significant attacks against [WebGL] may be possible". This is clearly an area that bears watching.