Though Internet Explorer 9 has made great strides in improving Internet Explorer's standard support, and version 10 is similarly set to include a whole range of new features, one thing that Microsoft hasn't even touched is WebGL, a specification that allows webpages to create 3D graphics using an API based on the venerable OpenGL API. A blog post today from the company's security engineers may explain why: they don't think there's any way to implement it safely.
Three main concerns are enumerated in the post: WebGL exposes too much sensitive, privileged, or unhardened code to the Web; depends too heavily on third-party code for security; and is too susceptible to denial of service attacks. The first of these is perhaps most significant. Video hardware and video drivers are traditionally only exposed to relatively "trusted" code—programs that the user has explicitly chosen to install. Display drivers are notoriously unstable and buggy, and developers of 3D software have to go to quite some effort to ensure their programs do not use (or misuse) the 3D hardware in such a way as to cause problems.
Webpages often contain hostile code, deliberately written to provoke bugs and flaws in software. To combat this, browsers themselves are typically hardened, through use of sandboxing, privilege reduction, and other techniques, to minimize the impact of flaws; they're also vigorously analyzed to detect such issues, and coded in such a way as to aggressively detect misuse and handle such situations safely—in no small part as a result of a long history of browser-based exploitation. In the past, video drivers have never had to face this kind of threat, and so have never been written to cope with this kind of problem, often preferring to simply trust that 3D developers will do the right thing. WebGL changes this picture, and gives hostile webpages relatively free access to attack vulnerable drivers.
This brings up the second point—many of these flaws don't exist in the WebGL specification itself, but rather in the display drivers written by ATI, NVIDIA, and Intel. This makes it difficult for a browser vendor to effectively combat them; although attacks may be delivered by the browser, it's not the browser that's being exploited. The best the browser can do is to blacklist known-vulnerable drivers, but this in turn leads to a very uneven user experience. WebGL was not written in a vacuum, and some of these issues were considered in its design. OpenGL has also had features added that enable the underlying drivers to perform stricter validation of 3D code, with the specific intent being to make WebGL scenarios safer. Microsoft's third point is that these techniques aren't proven and are likely to be incomplete (the post specifically mentions a forthcoming OpenGL extension designed to improve WebGL security that extends an existing extension that's not sufficiently robust). Taken together, the company says that these issues mean that any WebGL implementation would not meet the company's internal standard for software security.
Though once the idea of Microsoft rejecting something on security grounds may have been considered laughable, the substantial efforts in creating new software development methodologies and embedding security into every aspect of a product's design and development have paid off; Windows Vista and Windows 7 have both had a substantially better track record than Windows XP when it comes to security flaws, both suffering fewer flaws than Windows XP and reducing the severity of many of the bugs they do have. The reluctance to implement a specification that doesn't abide by the security guidelines that have served the company well in recent years is understandable. Cynics might argue that the security argument is a smokescreen and that this is simply Microsoft once more rejecting an open standard in favor of its own, proprietary, Direct3D. That interpretation is harder to defend against a backdrop that has seen Microsoft actively participating in the development of HTML5 and vigorously promoting the use of open HTML5 standards—even at the expense of its own technology. The company appears to be making a good-faith effort to do the right thing, at least with regard to HTML5 and related specifications.
Microsoft also isn't alone in having a problem with the quality of video drivers. Firefox 4, like Internet Explorer 9, uses Direct2D and Direct3D to accelerate the drawing and animation of webpages. These APIs, both hardware accelerated, are heavily dependent on driver quality. Although the use of these APIs is in many ways quite controlled and restricted—it's Firefox calling them, rather than WebGL JavaScript calling them—the Firefox developers have still had to blacklist a large number of drivers, especially older ones, due to problems with crashes and screen corruption. They're simply not predictable enough or consistent enough to be usable without testing, and when they crash, the effects can be disastrous. Redmond may face a similar issue itself; Silverlight 5, which will be used for browser-based applications among other things, will include some support for Direct3D graphics. This could open browsers up to many of the same problems as WebGL—at least for those systems with Silverlight 5 installed and enabled. WebGL is in many ways a natural counterpart to the 2D Canvas API that many browsers—including Internet Explorer 9—support, extending browser graphics into the third dimension. Its omission is sure to earn some degree of criticism from other developers, especially as Microsoft's criticisms of WebGL are unlikely to encourage Mozilla, Google, or Apple to drop the technology. The blog post does acknowledge the desirability of WebGL-like technology, but says that the company won't implement anything that doesn't meet its security requirements. If WebGL won't, it's hard to see what will.
Three main concerns are enumerated in the post: WebGL exposes too much sensitive, privileged, or unhardened code to the Web; depends too heavily on third-party code for security; and is too susceptible to denial of service attacks. The first of these is perhaps most significant. Video hardware and video drivers are traditionally only exposed to relatively "trusted" code—programs that the user has explicitly chosen to install. Display drivers are notoriously unstable and buggy, and developers of 3D software have to go to quite some effort to ensure their programs do not use (or misuse) the 3D hardware in such a way as to cause problems.
Webpages often contain hostile code, deliberately written to provoke bugs and flaws in software. To combat this, browsers themselves are typically hardened, through use of sandboxing, privilege reduction, and other techniques, to minimize the impact of flaws; they're also vigorously analyzed to detect such issues, and coded in such a way as to aggressively detect misuse and handle such situations safely—in no small part as a result of a long history of browser-based exploitation. In the past, video drivers have never had to face this kind of threat, and so have never been written to cope with this kind of problem, often preferring to simply trust that 3D developers will do the right thing. WebGL changes this picture, and gives hostile webpages relatively free access to attack vulnerable drivers.
This brings up the second point—many of these flaws don't exist in the WebGL specification itself, but rather in the display drivers written by ATI, NVIDIA, and Intel. This makes it difficult for a browser vendor to effectively combat them; although attacks may be delivered by the browser, it's not the browser that's being exploited. The best the browser can do is to blacklist known-vulnerable drivers, but this in turn leads to a very uneven user experience. WebGL was not written in a vacuum, and some of these issues were considered in its design. OpenGL has also had features added that enable the underlying drivers to perform stricter validation of 3D code, with the specific intent being to make WebGL scenarios safer. Microsoft's third point is that these techniques aren't proven and are likely to be incomplete (the post specifically mentions a forthcoming OpenGL extension designed to improve WebGL security that extends an existing extension that's not sufficiently robust). Taken together, the company says that these issues mean that any WebGL implementation would not meet the company's internal standard for software security.
Though once the idea of Microsoft rejecting something on security grounds may have been considered laughable, the substantial efforts in creating new software development methodologies and embedding security into every aspect of a product's design and development have paid off; Windows Vista and Windows 7 have both had a substantially better track record than Windows XP when it comes to security flaws, both suffering fewer flaws than Windows XP and reducing the severity of many of the bugs they do have. The reluctance to implement a specification that doesn't abide by the security guidelines that have served the company well in recent years is understandable. Cynics might argue that the security argument is a smokescreen and that this is simply Microsoft once more rejecting an open standard in favor of its own, proprietary, Direct3D. That interpretation is harder to defend against a backdrop that has seen Microsoft actively participating in the development of HTML5 and vigorously promoting the use of open HTML5 standards—even at the expense of its own technology. The company appears to be making a good-faith effort to do the right thing, at least with regard to HTML5 and related specifications.
Microsoft also isn't alone in having a problem with the quality of video drivers. Firefox 4, like Internet Explorer 9, uses Direct2D and Direct3D to accelerate the drawing and animation of webpages. These APIs, both hardware accelerated, are heavily dependent on driver quality. Although the use of these APIs is in many ways quite controlled and restricted—it's Firefox calling them, rather than WebGL JavaScript calling them—the Firefox developers have still had to blacklist a large number of drivers, especially older ones, due to problems with crashes and screen corruption. They're simply not predictable enough or consistent enough to be usable without testing, and when they crash, the effects can be disastrous. Redmond may face a similar issue itself; Silverlight 5, which will be used for browser-based applications among other things, will include some support for Direct3D graphics. This could open browsers up to many of the same problems as WebGL—at least for those systems with Silverlight 5 installed and enabled. WebGL is in many ways a natural counterpart to the 2D Canvas API that many browsers—including Internet Explorer 9—support, extending browser graphics into the third dimension. Its omission is sure to earn some degree of criticism from other developers, especially as Microsoft's criticisms of WebGL are unlikely to encourage Mozilla, Google, or Apple to drop the technology. The blog post does acknowledge the desirability of WebGL-like technology, but says that the company won't implement anything that doesn't meet its security requirements. If WebGL won't, it's hard to see what will.
News Source http://arstechnica.com/microsoft/news/2011/06/microsoft-no-way-to-support-webgl-and-meet-our-security-needs.ars
No comments:
Post a Comment