News

WebGL Security – Kill it before it grows?

When Khronos launched the WebGL specifications with strong backing from Mozilla, Google, Apple and Opera we thought at least peace had come to the 3D web valley. We should have known better; seems that there are competing vested interests in proprietary software and plug-ins that will put a few bumps in the road in WebGL’s journey to pervasiveness. Last week ...

Robert Dow

When Khronos launched the WebGL specifications with strong backing from Mozilla, Google, Apple and Opera we thought at least peace had come to the 3D web valley. We should have known better; seems that there are competing vested interests in proprietary software and plug-ins that will put a few bumps in the road in WebGL’s journey to pervasiveness.

Last week we were told by Microsoft, the developers of Silverlight, that WebGL is a giant piss-hole into which any yahoo can pour viruses, spoofs, and even DoS attacks – ack! The sky is falling run run run.

In a post by James Forshaw of Context, “an independent information security consultancy,” in London, it is suggested WebGL is a great big welcome sign to all the malcontents and malicious code writers on the web, which we assume number in the millions.

Some have suggested that WebGL needs to be redesigned from the ground up due to security concerns.

Context’s view of the vulnerability of the graphics pipeline (source Context)

Khronos as you might expect, has answers to these concerns. Khronos’ view is that any new browser capability exposes new code that inevitably needs to be hardened. Any GPU accelerated capability – be it HTML, Canvas, WebGL, Adobe Molehill, Silverlight 5, etc. – will require the graphics drivers to be hardened. This is an inevitable process that needs to be managed carefully – and WebGL is the right technology to spearhead this process as it has the backing of the browser and GPU communities.

Khronos says they would welcome Context and/or Microsoft to join Khronos to help the industry move forward on secure, accelerated graphics for the Web.

Why has this come up?

It looks a little suspicious that the Microsoft Blog appeared on the same day as a Context security report that it was referring too. Why would Microsoft do such a thing? Some suspect that as Silverlight 5 will include 3D that some don’t want to see WebGL become widely used.

Conspiracy theories aside, Context did raise two valid issues to be addressed by the WebGL implementations as the industry goes through the hardening process. Context demonstrated that a shader program could implement a loop that could be used to approximately reconstruct an image from another domain – a serious potential security hole. Khronos had previously debated on its open mailing list whether this was a real-world possibility and once the exploit was demonstrated by Context worked swiftly with the WHATWG working group to mandate the CORS spec in both the HTML and WebGL specs to make sure servers have to explicitly allow access to media assets across domains.

The second valid concern raised by Context is that a WebGL shader program can, deliberately or not, take a long time to execute, causing the graphics card and system to become unresponsive, effectively a DoS attack. Khronos is fully aware of this and has posted a security white paper that explains how the group has developed ARB robustness extensions to enable a system to cleanly recover from such a situation and discussed other security issues: http://www.khronos.org/webgl/security/

Confusion in the industry as we start this hardening process

As the Context comments reports get widely reported in the press – there is a certain amount of misunderstanding around what GPU shaders are, and are not, capable off – leading to some rather hysterical fears about shader programs overwriting your disk drive and the like. Of course, GPU shaders are much more restricted in their capability than for example JavaScript running on the main CPU. Shader programs can only execute a small set of operations that revolve around computing colors and vertex positions and WebGL shaders are more restricted than OpenGL shaders (e.g. no dynamic control flow, etc) to increase portability. Additionally, WebGL implementations validate shaders to ensure there is no way to access illegal/arbitrary memory.

It’s clear that WebGL needs to continually educate the industry on the technology and the process underway here. The next step is that Khronos is preparing an imminent WebGL 1.0.1 release that will fix bugs in the current conformance tests and tighten the screws on resolving any security issues that have arisen. 1.0.1 should start allaying fears in the industry as the spec will take a 100% robust stance on security and implementations that pass the conformance tests will be able to remove the “experimental” from the getContext(“webgl”) query – giving content the confidence they are running on a secure WebGL implementation.

What do we think?

The basic security concern is that graphic drivers are being exposed to the Web in more direct ways than before – which is true – and they will need to be hardened. But that’s true of WebGL, Adobe Flash, Silverlight AND Canvas. If we can never expose any graphics drivers to the web – we can never have ANY GPU graphics in the browser – and that’s not going to happen.

Khronos has the right attitude that this is an inevitable process that needs to be carefully managed. This is why Khronos is precisely the place where WebGL needs to be developed -we need the GPU and browser vendors working side by side to make sure the browsers and graphics drivers work together to provide overall security.

If these security reports are smear tactics then they never work, always backfire, and if sponsored by Microsoft will do more to discredit the company than help it. Consumers are a lot smarter today than too many manufacturers give them credit for. And as been proven in the Mideast, communications among peers and friends is at the speed of light. There’s an awful lot of smart people in Khronos and this isn’t their first time at bat. They know the issues, know how to deal with them and they will. If Context is looking for PR, we suggest a better path would have been for them to have taken their concerns directly to Khronos. And if Context is really seriously interested moving the industry forward they should join Khronos and help fix any problems they discover.

However – security issues and bugs always occur – so we will be watching carefully to see how Khronos manages the situation. In the shorter term when issues arise browser vendors are maintaining white and black lists so compromised system can have WebGL disabled until mitigation is developed. Longer term we expect GPUs will provide increasingly robust security and multi-tasking to enable the GPU to truly become a first-class computing platform alongside CPUs.