In the last few months, we have seen the release of several new browser versions, including Mozilla’a Firefox 4, Google’s Chrome 11, Microsoft’s Internet Explorer 9 (for Windows 7 and Vista only), and Oslo’s favorite browser, Opera Software’s Opera 11.10 . Each of these has its own set of special features and distinguishing characteristics, but one common theme in recent releases has been providing improved support for HTML 5, the next version of the content description language used to create Web pages. The draft specification for HTML 5 is impressively long, and it is important to note that it is a work in progress, but there are a couple of unifying themes underlying the changes. The first is to attempt to arrive at a truly standard language, rather than the mostly-standard with accumulated “stuff” nature of HTML 4. The second is to provide a better format for supporting Web-based applications.
One of the new elements introduced in HTML 5 is
WebGL also allows Web pages and embedded applications to access and take advantage of the hardware acceleration capabilities present in some high-end graphics processors [GPUs]. The mention of hardware access by external code should have made security-conscious readers nervous; and a UK security consulting firm, Context Information Security, has published a report outlining what they believe are some potentially serious security problems with WebGL. They argue that there are defects in both the design and implementations of WebGL, which expose users to significant risks:
- It may be possible to provide malicious code, via the WebGL-enabled browser, that incorporates attacks on the GPU and graphics drivers, creating a Denial-of-Service [DOS] attack that renders the whole system unusable.
- It may be possible to use WebGL to steal graphics image data from other sites.
- The current design allows arbitrary, Turing-complete programs to be sent to the GPU. Since graphics drivers typically operate at the highest privilege level (kernel mode), this is a significant vulnerability.
The Context IS article also has some more detailed discussion of the mechanisms involved, and links to some simple examples.
Currently, WebGL support is present, and enabled by default, in the Firefox 4 and Google Chrome browsers. Support for WebGL is also present in Apple’s Safari browser.
The US-CERT coordination center has also published a brief notice, recommending that users take note of these results, and consider disabling WebGL support when it is not required.
US-CERT encourages users and administrators to review the Context report and update their systems as necessary to help mitigate the risks.
The Khronos Group has also published a brief note, outlining some current and proposed security enhancements to the WebGL specification.
I’m not aware of any evidence that practical exploits have been developed for these vulnerabilities, and I’m sure that more information will be forthcoming on this subject. Not many sites use WebGL yet, and it may well be that existing mechanisms in at least some browsers may mitigate some potential attacks. However, for sensitive Web applications, like on-line banking, I would suggest disabling WebGL in those browsers (Firefox and Chrome) that enable it by default. The instructions for doing this are below.
Disabling WebGL in Firefox is done from within the running browser; the setting persists across browsing sessions Follow these steps:
about:configin the URL box.
- Find the entry
webgl.disabled. (This is most easily done by entering
webglin the “Filter:” box.)
- Highlight the
webgl.disabledline; its value should be “false”
- Right-click on the line for a context menu.
- Click “Toggle” to change the value from “false” to “true”.
Disabling WebGL in Chrome requires that you specify the argument ‘
--disable-webgl‘ on the command line when Chrome is started.