Posted May 26, 2011 4:34 UTC (Thu) by bjacob
Parent article: WebGL vulnerabilities
I'm disappointed to see this article on LWN since this has been a huge press failure 2 weeks ago and I was happy that LWN had stayed away from it.
The Context announcement had one useful bit of information: that the timing attack on shaders to get cross-domain images, that had been theorized on the public WebGL list (their announcement links to the archived email), was actually implementable. That was indeed important news --- I just wished Context had followed the standard practice of letting browser vendors know sufficiently ahead of time to fix the bug before it becomes public. Anyway, this has been the top area of focus of the WebGL working group since. You can track Mozilla's response to this here:
Unfortunately, this interesting part of Context's blog post is not what caught the most attention from the press. Rather, what generated the most noise was Context's bold claims about the possibility of exploits:
"Fundamentally, WebGL now allows full (Turing Complete) programs from the internet to reach the graphics driver and graphics hardware which operate in what is supposed to be the most protected part of the computer (Kernel Mode)."
This sentence is wrong on several different levels, since WebGL shaders (contrary to desktop OpenGL shaders) are not Turing-complete, they run on the GPU where there is no such thing as "kernel mode", and in case they were instead talking about the shader compilers, these certainly don't run in kernel mode.
Context never says clearly that there are WebGL code execution exploits, but makes a series of vague claims like the above, and like this gem:
"These issues can allow an attacker to provide malicious code via a web browser which allows attacks on the GPU and graphics drivers. These attacks on the GPU via WebGL can render the entire machine unusable."
The key in the above sentence is "can". The English language is vague enough that "can" could mean "might perhaps" or "can for sure". This allowed Context, without ever claiming clearly that they know of any code execution exploit, to generate a huge stream of press articles.
Regarding the DOS issue, this has been openly discussed since the beginning, and WebGL has been very influential in nudging GPU makers to reduce the DOS risk. This has concretized in the form of the GL_ARB_robustness extension and a GL_ARB_robustness_2 extension is planned. Let's not forget that DOS risks are omnipresent, even without WebGL: for example, just creating a large array, reduces the amount of RAM available for other tasks. So handling DOS is all about mitigation and not about eradication. That's why Context is missing the point when it claims that ARB_robustness is not a solution to the DOS problem. To further put Context's claims into perspective, let's mention that WebGL doesn't even show up among the top 300 Firefox crashers:
Of course the DOS problem is not only about Firefox crashes, but you get the idea.
Context is also wrong when it downplays the effectiveness of graphics driver blacklists. During the Firefox 4 Beta process, graphics driver bugs have often been the top crashers. Blacklisting has allowed to eradicate these crashes, to such an extent that they are no longer a significant source of crashes (see above crash-stats link). Blacklisting is also used to avert any kind of security flaw that we find. Firefox crash reports contain the information that we need to update the blacklist in an almost automatic way, and we can ship blacklist updates without requiring a software update. Moreover, by proactively documenting our blacklist,
we enable collaboration on it with other browser vendors, and this is already happening with another major vendor.
to post comments)