Context Information Security, an independent information security consultancy, has published a new report on security flaws with WebGL. The report, “WebGL–More WebGL Security Flaws,” includes a video clip demonstrating why organizations should think twice about relying on Web browsers built on WebGL.
After Context first published its findings that WebGL exposes systems to security risks, Khronos, the developers of WebGL, and browser vendors have stepped up and taken action to address those concerns. This new report is based on continued research by Context, as well as testing done to determine if the actions taken by Khronos and browser vendors actually work to make WebGL safe.
In a nutshell, it appears the answer is “no.” What is the risk? In order to deliver advanced graphics and 3D rendering from the Web without introducing lag and impacting performance, WebGL interacts with the graphics driver at a core level. The low-level functionality of the graphics processor has always been shielded from executable code, and was not designed with security in mind. WebGL exposes the low-level core functions of the system to possible malicious exploits.
Context stresses in the new report that it is not unusual to find security issues with a new technology, but that it is crucial to identify and mitigate those issues as quickly as possible to minimize risk and protect users. Context reviewed conformance tests developed by Khronos designed to assess compliance with the WebGL standard using a variety of operating systems, browsers, and graphics hardware.
“Through this work Context has discovered that neither Chrome nor Firefox passed the Khronos tests, including a number that are directly related to security. Context then explored the consequences of one of the failed conformance tests. The issue it identified allowed us to extract images containing data from the user’s desktop and from other Web browser sessions such as authenticated pages.”
A Microsoft Security Research & Defense blog post explains, “The security of WebGL as a whole depends on lower levels of the system, including OEM drivers, upholding security guarantees they never really need to worry about before. Attacks that may have previously resulted only in local elevation of privilege may now result in remote compromise,” adding, “While it may be possible to mitigate these risks to some extent, the large attack surface exposed by WebGL remains a concern.”
Andrew Brandt, lead threat research analyst for Webroot, points out, “The simplest thing is to just disable WebGL in your browser. There’s no need to avoid using Firefox or Chrome just because they support WebGL, but I’d definitely recommend disabling it for the time being.”
Brandt adds that there is little incentive to leave WebGL enabled when there are few sites that actually rely on the technology, and there are these known security issued to contend with. “Leaving it enabled is just inviting trouble,” he says.
Tim (TK) Keanini, CTO of nCircle, points out, though, that Firefox and Chrome are at least in a more agile position when it comes to responding to threats. “What Chrome and Firefox have going for them is they have a cheap, fast way to update their products. The bad guys want to keep any zero-days they find secret because once the bug is out there it gets fixed much faster with these tools than with other systems.”
Organizations should disable WebGL pending changes to the standard, and implementation of the technology by the individual browsers that close these security holes. Doing so will impact the capabilities of the browser and the overall Web experience, but that is preferable to leaving systems exposed to unnecessary risk. An alternate solution is to consider adopting a browser that does not support or rely on WebGL, like Internet Explorer.
