Submitted by “Mozilla’s VP of Technical Strategy, Mike Shaver has rejected Microsoft’s criticism of WebGL in which it said it would not implement the 3D graphics standard because of security issues in the design. Shaver says that “there is no question that the web needs 3D capabilities” to enable developers to create “advanced visualisations, games or new user interfaces” and points at Molehill (Adobe’s 3D for Flash) and Microsoft’s Silverlight 3D which are offering just those capabilities.” One discussion of Microsofts WebGL criticism can be found here.
I was pretty surprised at how easily the tech reporting crowd (even normally good ones, like arstechnica) swallowed and propagated the idea that WebGL is insecure by design. There’s nothing insecure about it’s design – only implementations that expose low level, unhardened APIs are insecure – but that’s just an implementation problem.
Microsoft knows that, and their PR department proved adept at exploiting the fact that so few other know what they are talking about.
I was surprised, too: at Microsoft, for making such a bold claim. The only credibility they might have for making it, comes from a “look, now we’re being SERIOUS about security!”. Which is just so much BS.
One only needs to look at Microsoft (later Rational) Visual Test, to see how one program could use the Windows API to abuse another running program. It was designed that way. I should know; I used Visual Test for a while, as the primary duty of my job.
Microsoft’s criticisms don’t pass Hanlon’s Razor; calling them “disingenuous distractions” is giving them too much credit.
I don’t think Microsoft ever said the design was flawed. They just pointed out that the implementation is usually very flawed, because it is written by nVidia, AMD and they aren’t very good at producing bug-free drivers, even for trusted code!
That said, Flash exposes exactly the same drivers, and MS don’t seem to have a problem with that (not that they have much choice).
Just because Flash or MS or Mozilla, etc. uses a low level API (and they all use a lot of low level APIs, including for their JIT systems), doesn’t mean they are “exposing” an API. That’s the problem with the entire argument.
The only thing valid in what they said is that exposing a low level API like that would be a security problem. That doesn’t mean you MUST expose low level APIs to implement another 3D API.
Microsoft are in a damned if they do and damned if they don’t scenario.
1) If they don’t implement it … they will be accused of vendor lock-in, FUD etc.
2) If they backtrack and do implement it, they will either be opening up Windows to a massive security risk (if what they say is true) or they will have seen to be doing number 1) at this time.
1) They deserve that, cause it’s true.
2) There is no security risk if it’s implemented properly.
If Microsoft dislikes hard spots, they should stop putting themselves in one.
BTW, watch for it: Microsoft will announce a new 3D API based on it’s “familiar” Direct 3D technology, built with “security in mind from the ground up” and “for the modern web” or something similar.
Then you’ll get WebGL-Ex or something similar, which will be a WebGL wrapper library written in JavaScript to convert WebGL calls (and translate shaders) to whatever API Microsoft runs with. Google might release a shim. It’ll be the same as it has been for the last 15 years. You don’t need to worry about that. 😉
How do you know this? Are you an expert in 3d graphics, WebGL, Windows Driver model and Internet Explorer?
I’m a web developer (and a particularly paranoid one about security) who uses abstracted APIs regularly, and an OS enthusiast (duh, I’m on osnews.com) who’s been following this stuff for over 15 years. I don’t need to be an expert in any of the specific areas you listed, because what I’m talking about is an abstract principle of software development. Any API can be implemented, on top of any other API, and as long as the API design is sound, you can implement it in a secure way. Even if the API specification isn’t secure by design, it is certainly possible to figure that out during implementation, and adjust the spec accordingly. This is really basic stuff in software development.
The second article lists the issues that Microsoft has with WebGL and I think they are valid concerns.
The Mozilla argument ignores the issues presented by Microsoft, and instead tries to reframe the discussion about whether the web should get 3d acceleration – which is not the issue that Microsoft is talking about.
The issue is how should the web get 3d acceleration and the questions/issues MS brings up about exposure of present drivers is a valid issue.
Saying “oh yeah the driver developers are committed” doesn’t really make a counter argument.
WebGL does have some very serious design flaws. When you have access to pixel shaders, you can essentially read video buffers which are located on the graphics card & used by other applications (and other browser sessions). This is essentially like having access to the contents of Print-Screen. The potential for information theft is HUGE. I think we should take a step back and analyze this stuff critically, and not demagogue Microsoft because someone’s desperate to put a 3D Web standard in place before MS co-opts them. Because a potentially BAD standard is worse than none at all.
I don’t know anything about WebGL, but shouldn’t it be possibly to write a code verifyer that checks the shader source if it possible makes insecure operations? Yes, this would only allow a subset of what is otherwise legal GLSL, but shouldn’t that subset it be enough (I don’t know; I ask you)? And this could do the Browser before it sends it to the graphics card. If Google can do that with NaCl why not Mozilla/Google/Microsoft/… with WebGL?
From the second article …
And then this further on …
Seems to suggest to me that Microsoft sees potential WebGL security problems similarly to the security problems we have had with 3rd party plugins for browsers such as Flash and Java Runtime Plugin … well that is the way I read it.
Edited 2011-06-21 22:20 UTC
There’s not really such thing as “insecure operations”. There are bugs, which can lead to exploits. If a program could be written that detected bugs a great many problems in the computing world would be solved. 🙂
It would definitely be possible to check indices, etc. I believe one of the Chrome developers discussed this in a blog post on HN.
Graphical stacks are all but safe. Also they are one of the most complex software components of the entire OS, and then also rely on a very direct means of hw access for raw speed.
Purpose of GL/D3D to these days is to compile shader code, do some validation and pass it as a command buffer to the hardware. They also apply some restrictions on memory access and to avoid deadlocking by apps. Yes they do all the fancy API mangling, but it boils down to above, and when this cooked instruction packs are transferred to kernel portion and hw, problems arise.
First, don’t blame MS, they did much to improve situation by requirements on Vista driver model (at least for 2.0, but I don’t know where they got with vendors). So maybe latest few generations by AMD and Nvidia hardware is robust enough, but most hardware around is still DX9 class – inherently secure to untrusted shaders and other mangling. In short, graphic hardware in most desktops and laptops is too rudimentary to support hw level insulation like e.g. CPU’s, so it has to be done by validating every bit of code that runs on them. Complementary problem is drivers, for which security was never an issue, and were instead every last bit optimized to run fast on 3DMark and and new games.
While there is a lot of software “validation” in drivers, and probably not yet as mature one in browsers, the DoS is pretty much practical and easy, I’d say hard to avoid on most common HW/OS/driver combination. Ever had a game freezing your machine due to a game or driver bug?
So, yes even a perfectly legal WebGL shader code could create problems, and maybe even comprimise machine with some probability.
IMHO, WebGL opens up too much phase space at once, and MS is certainly going to be blamed for a lot of it. Actually Linux, Apple have it on their hands as they mantain and know their own driver code.
Good side of this is that at last there is time to address these “little” problems, and force GPU manufacturers to produce secure hardware and drivers. I think for AMD/Nvidia the latter is bigger issue. For some hardware it might mean retirement or disabled Web GL – not sure about Intel, my i965 windows driver hasn’t received update in years, so how is this going to suddenly change for the better?
Have a read:
http://games.greggman.com/game/webgl-security-and-microsoft-bullshi…
I think the driver issue with ATI and Nvidia is very real, to a slightly lesser extent with Intel.
It may be solved in the future, but until there is (and if there is) ever a standardized graphical stack that is open source (OpenGl for instance), it will be really tough to ever get this to an acceptable security level.
isnt so much with having a 3d accelerated web, its with giving basically any web developer low level access to baremetal graphics APIs (be they Direct3d or OpenGL).
Actually, its even worse with OpenGL since driver vendors themselves actually implement OpenGL (As opposed to say Microsoft implementing it.) So besides the built in (slow) OpenGL 1.4 ICD, everything else relies on AMD or nVidia to release an OpenGL driver for the system (meaning the full stack, not just a kernel mode driver).
So basically, it wouldn’t be as big a problem (though still a problem) if the API was a little more abstracted. You’ll notice that Silverlight or Flash don’t give you direct access to OpenGL or Direct3D, its filtered through a higher level API (which then can perform sanity checks on user input) and things like the pixel shader support is verified safe (both thanks to sanity checking, and the inherent type safety of the .NET CLR in Silverlight).
Really, WebGL is a very clunky, clumsy, avoidable mess. We’ll be opening a pandora’s box of security nightmares if this thing gains any sort of critical mass.
Adobe created their own API code named “Molehill” (now called Stage3D) – they have a layer that translates that into the underlying native API (D3D or OpenGL EX 2.0). It’s a uses-a relationship, not an is-a.
WebGL is an API which is much like OpenGL EX 2.0, but not exactly the same – essentially it’s own API, just like Molehill.
Why is it necessary in the minds of damn near everyone talking about this issue to create a WebGL implementation that is little more a wrapper to insecure low level system APIs, rather than implementing WebGL as the exact same level of abstraction that Adobe has created for Flash with Molehill (or MS with SL)? In fact, don’t some of the WebGL (most maybe) on Windows translate to D3D on the back side?
Microsoft won this PR campaign.
WebGL is extremely low-level and OpenGL-like, which not only makes it hard to work with, it also matches up very poorly with how web APIs are usually designed. If on top of this it is expected that all implementations should invent some kind of virtualization which wraps this low-level API in sufficiently high-level constructs to make the runtime somewhat controllable we have officially arrived at the worst of all possible worlds. It is really telling that WebGL brings along with it its own type of native typed array in Javascript to try to make it perform, it is simply an alien creature to the environment.
The part where you are correct is that a more managed implementation of 3D on the web is what is needed. WebGL is just not the way to do this, more likely some type of retained-mode scenegraph integrating with the DOM is the way to go. That still leaves the question of how to handle shaders. For a first version I would think just having a fixed library of parameterized shaders would be a good way to go (notably this is what Microsoft does in XNA, to avoid exactly the problems where the supposedly managed games would do weird unportable and possibly insecure things on the graphics hardware).
In short, security is only one of the reasons why WebGL is ill conceived from the start. It is like if instead of the current canvas-tag Apple would had made a slightly modified svgalib.h available in Javascript.
The same could be said (and has been said) about Canvas 2d – it’s too low level, has no retained mode, etc. SVG is better, the DOM, higher level, etc.
It doesn’t matter – Molehill is a similar low level API to WebGL. Just because it’s a low level looking API that uses another low level system API, doesn’t mean an implementation has to be insecure (and plenty of folks keep pointing to Molehill – which is just as low level as D3D or OpenGL).
Really the issue is only clouded by the fact that WebGL looks a lot like OpenGL and has GL in the name. Maybe if they called it Canvas3D instead of WebGL it would have been better…
The same cannot be said about canvas, just compare the texture management in WebGL (complete OpenGL-style with registering, binding, format management, manual freeing, mip-map generation, etc.) to canvas approach of just letting you draw random image elements onto the canvas.
Also taking Flash and Molehill as the gold standard of how to do security and design open APIs on the web is not something I would do. Even if Molehill decided to explicitly specify remote code exploits that would in fact not be a good argument for making remote code exploits a web standard.
There is still an assumption in your premise here – that the WebGL API must by necessity be implemented with a thin later, on top of a compatible low level API. This is simply not true. In fact, many of the existing WebGL implementations are built on top of D3D.
After looking into the issue more, it seems you (and others) are right. The security issues seem no more pronounced than what one would encounter with Silverlight or Flash.
In fact; I learned that in some cases, WebGL layers ontop of Direct3D (way cool) so the security issues imho are greatly diminished.
In other words, nearly every issue I voiced in my previous comment was a misunderstanding and I apologize.
Smells like FUD to me.
Rubbish. Direct3D is not meant to be called directly by untrusted code. It allows you to read textures located on the graphics card which don’t belong to you, do all kinds of nastiness with pixel shaders, including DoS your machine. The WebGL layer on Direct3D is overly thin and insufficiently abstracted. It essentially invites untrusted code to *#@k your machine.
The arguments I’m hearing about WebGL being insecure are somewhat plausible. The programmable shaders might be told to copy arbitrary memory from the graphics card, and therefor compromise on the security of other applications using the graphics card (including the main desktop).
Am I understanding correctly?
Assuming the above is true, it would seem that the problem is not limited to WebGL at all. Any local unprivileged directx program would have access to the full graphics ram.
Don’t MS/apple do anything about this today? Given the win-kernel DRM MS forced upon us, I’d be shocked if they weren’t doing something to block access to video buffers by rogue apps.
Of course, as others have said, the solution is obviously to provide a safe API for web pages, one which doesn’t allow the web developers to access arbitrary graphics ram in the first place.
The idea is that the driver should isolate different programs properly, but since the graphics APIs aren’t usually exposed in insecure contexts, and do everything they can to improve performance, they are well known to have constant issues even when the developers try to avoid them.
It is a surprisingly common occurrence when writing an OpenGL program to somehow mismanage ones textures and ending up with what appears to be a screenshot of another program plastered on ones models. And that is by accident, if you tried there are bound to be a lot of ways in a lot of drivers to sneak out information.
This is a transparent appeal to authority, but John Carmack is pretty on top of the technology involved, and is a well-known friend of the open source ecosystem, and he also weighs in on the side of Microsoft here:
http://twitter.com/#!/ID_AA_Carmack/status/81732190949486592