Microsoft declares WebGL ‘harmful’ to security

/* Posted June 16th, 2011 at 2:53pm    */
/* Filed under Web    */

A security firm raised new concerns today about WebGL–but Microsoft piled on with an opinion that’s likely more damaging to fans’ hopes for a universal 3D Web graphics standard.

“We believe that WebGL will likely become an ongoing source of hard-to-fix vulnerabilities,” Microsoft said today in a security blog post flatly titled “WebGL Considered Harmful.” “In its current form, WebGL is not a technology Microsoft can endorse from a security perspective.”

The move effectively kills WebGL fans’ hopes, at least for now, that WebGL could become a standard Web programmers could count on finding in modern browsers. And that means one hot area of programming, games development, won’t have an easy, unified way to tackle Web-based software.

WebGL was created initially at Mozilla, standardized by the Khronos Group, and supported by Google. It’s built into Chrome and
Firefox right now, giving those browsers a way to display hardware-accelerated 3D graphics useful for games and other visually rich tasks.

As with many technologies, though, the security scrutiny picks up once the technology leaves the labs and enters the real world. Today, Context Information Security, which issued a WebGL warning in May, issued another caution.


Google Body demonstrates WebGL features. The Google Labs site has a slider that lets you add or remove various systems of the human body.

Google Body demonstrates WebGL features. The Google Labs site has a slider that lets you add or remove various systems of the human body.

(Credit:
screenshot by Stephen Shankland/CNET)

Specifically, Context publicized a problem that could let a Web site capture a screenshot of a Firefox user’s computer, the company said in a blog post. It found the problem by checking Firefox with Khronos’ WebGL conformance tests, which it said Firefox and Chrome don’t pass. It also called insufficient Khronos’ response to the earlier concern, employing a feature called GL_ARB_robustness.

“Context therefore recommends that users and system administrators disable WebGL,” Context concluded.

Khronos downplayed the concerns in a statement from spokesman Jonathan Hirshon:

1. All browser vendors are still working toward passing the WebGL conformance suite. Only once they have successfully done so can they claim support of Canvas.getContext(“webgl”) instead of Canvas.getContext(“experimental-webgl”).

2. The issue of theft of arbitrary windows on the desktop is due to a bug in Firefox’s WebGL implementation, and cannot be generalized across other browsers’ WebGL implementations. Moreover, that bug was addressed May 26 and is resolved in Firefox 5, slated for release June 21.

3. Browser vendors are still in the process of supporting the GL_ARB_robustness extension, so it is expected that the previously reported denial-of-service issues are still present. It is expected that the reported denial-of-service issues will be solved with the integration of this extension.

Context’s warnings are reinforced by the practical reality that Microsoft just wrote it off. The company has been frosty toward WebGL, but today it publicized Context’s findings and explained why it views WebGL as unsafe.

Microsoft concluded that WebGL “would have difficulty passing Microsoft’s Security Development Lifecycle requirements,” a stance that seems likely to doom hopes at least for now that WebGL would become a standard supported by all major browsers. Universal support means that Web developers could count on WebGL being available and therefore could use it; its absence means that some Web sites and Web apps–Angry Birds for Chrome, for example–will require compatibility checks and fallbacks.

Among Microsoft’s views on WebGL’s security problems are the following:

The security of WebGL as a whole depends on lower levels of the system, including OEM [original equipment manufacturer] drivers, upholding security guarantees they never really [needed] to worry about before. Attacks that may have previously resulted only in local elevation of privilege may now result in remote compromise. While it may be possible to mitigate these risks to some extent, the large attack surface exposed by WebGL remains a concern…

As WebGL vulnerabilities are uncovered, they will not always manifest in the WebGL API itself. The problems may exist in the various OEM and system components delivered by IHVs [independent hardware vendors such as video card makers]. While it has been suggested that WebGL implementations may block the use of affected hardware configurations, this strategy does not seem to have been successfully put into use to address existing vulnerabilities. It is our belief that as configurations are blocked, increasing levels of customer disruption may occur…

Modern operating systems and graphics infrastructure were never designed to fully defend against attacker-supplied shaders and geometry [software that run on a graphics chip]. Although mitigations such as ARB_robustness and the forthcoming ARB_robustness_2 may help, they have not proven themselves capable of comprehensively addressing the DoS [denial of service] threat… If this problem is not addressed holistically it will be possible for any web site to freeze or reboot systems at will.

Don’t expect WebGL to vanish, though. The movement toward Web apps is powerful, with notable allies. And some of Microsoft’s concerns, such as the difficulties of assigning responsibility for plugging holes, aren’t as bad outside the Windows PC world. Windows PCs use a vast array of hardware combinations, but Apple computers, Google Chromebooks, and new-generation smartphones don’t.

And companies selling that technology are used to not having Microsoft on their side.

Tags:


Leave a Reply

or Login (not required)





HTML tags allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>