For background, I write a lot of WebGL demos, I work for Mozilla on gfx optimizations (WebGL and otherwise) for the Boot2Gecko project. I also worked at Matasano Security previously, doing WebGL security research. As such, I tend to think that I'm pretty unbiased in this regard -- or perhaps biased towards WebGL, since I love it and want to see it everywhere. So with all that said, your characterization of MS's security claims as "FUD" are complete and utter bullshit. WebGL has a substantial attack surface in the browser (large API dealing with many issues from cross-origin restrictions to handling buffer locking and texture sharing, shader verification and translation, not to mention all the code required to actually make this stuff fast, which is what I work on), and it's only the tip of the iceberg that is the 3d stack.
Below the browser you have the userland driver components, which do things like further shader verification and initial stages of the compilation, validating index buffers, and simplifying the command stream. Below that you have the kernel components, which largely trust the userspace to have done their job properly, then do things like compile shaders for the specific hardware and put things into the proper form to send it off to the GPU, as well as handling synchronization and locking and all that. Then below that, you have a massively complex piece of hardware that under most circumstances is fully able to touch every single bit of your system memory (thanks, DMA), and that doesn't care one bit about security; it assumes that everything coming from the kernel is 100% safe and intentional. If you tell it to copy memory from point A to B, it will do it without complaining. Meaning if you wanted to, say, write over kernel memory from a buffer in the browser...
So let's look at what needs to happen to get ring0 (kernel mode) access from WebGL: 1) get your payload through/around validation in the browser, using available APIs, 2) get through/around userland validation OR attack the optimization/compilation steps that occur at that layer, 3) potentially attack optimization/compilation steps that happen in the kernel component -- optional, since this layer may not be your target, 4) GPU does your work for you.
At most, you're talking 3 layers to compromise. Compare to real-world vulnerabilities against other parts of the browser (see also: Pinkie Pie) where you're involving dozens of steps, and suddenly this doesn't look too difficult. The tough part is that it requires a significant amount of domain specific knowledge, but I'm certainly not the only one with it.
WebGL, as awesome as it is, is a security risk. It's one caused primarily by the fact that GPU vendors have never had to care about security along these lines before. It will be solved eventually, but it's damn sure not solved now.
How many examples of this type of "just 3 layers" compromise have we actually ever seen being used as an "attack"? How many is that compared to the number of known attacks against browsers using non WebGL-related technologies?
Did you actually see the specific 'security' concerns that that MS shop put out? Part of it was a laughable demo of an 'attack' that actually did not compromise anything, and looked like a mock-up that would be used in a movie. Whether there are potential security concerns or not, the actual 'concerns' that MS and that company raised were definitely FUD.
I haven't seen any real-world attacks using WebGL yet; we probably won't for a couple years, since it's still very new technology and there's a lot to learn to be able to do even basic research there.
> Browser support for WebGL directly exposes hardware functionality to the web in a way that we consider to be overly permissive
The WebGL API -- outside of bounds checking and shader validation/translation -- is a direct conversion of the EGL API. This makes getting your data (legitimate or not) into the lower levels very easy. That cuts both ways, as I detailed.
> Browser support for WebGL security servicing responsibility relies too heavily on third parties to secure the web experience
Read: The security of WebGL depends on GPU driver vendors, who write terrible code. This point is well known by anyone who's worked on enough 3D code, or even just tried to fix graphics bugs in games by doing the driver update dance.
> Problematic system DoS scenarios
For the vast majority of GPUs, there's no way to set timeouts on rendering or shader execution, so DoSes are just downright trivial. This will be the first thing to get better, with the various robustness extensions that are coming.
All in all, I have absolutely no issues with what MS released on the subject.
"This makes getting your data (legitimate or not) into the lower levels very easy."
Bullshit. Completely unsubstantiated.
The browsers themselves are what are actually being compromised in reality, Microsoft by far more than others. The WebGL exploits are just theoretical. Every browser vendor is a third party.
Big fucking deal, somebody makes your browser or system freeze up.. like that is a new thing that you can't do with a browser or with Internet Explorer? Freezing the system isn't that easy to do with WebGL and depends on the specific setup of that machine. That's not a security concern, thats just a potential inconvenience.
I don't give a fuck what you dumbasses think, this is obviously Microsoft FUD. But its just another example of the sort of idiotic rationalizations that normally support the status quo.
Almost all of the iOS jailbreak vectors involve chaining together bugs and quirks in multiple different subsystems, to ultimately root the system.
These aren't theoretical concerns. Just because WebGL hasn't yet been exploited doesn't mean it'll never be exploited. And given the way WebGL works, a WebGL exploit may be a very serious problem.
Honestly, the problem is that there is no security model. These drivers were never supposed to be exposed to untrusted code. We have a long way to go before driver vendors pull their heads out of their collective asses and start producing good code, especially since it will most certainly come with steep performance penalties.
Below the browser you have the userland driver components, which do things like further shader verification and initial stages of the compilation, validating index buffers, and simplifying the command stream. Below that you have the kernel components, which largely trust the userspace to have done their job properly, then do things like compile shaders for the specific hardware and put things into the proper form to send it off to the GPU, as well as handling synchronization and locking and all that. Then below that, you have a massively complex piece of hardware that under most circumstances is fully able to touch every single bit of your system memory (thanks, DMA), and that doesn't care one bit about security; it assumes that everything coming from the kernel is 100% safe and intentional. If you tell it to copy memory from point A to B, it will do it without complaining. Meaning if you wanted to, say, write over kernel memory from a buffer in the browser...
So let's look at what needs to happen to get ring0 (kernel mode) access from WebGL: 1) get your payload through/around validation in the browser, using available APIs, 2) get through/around userland validation OR attack the optimization/compilation steps that occur at that layer, 3) potentially attack optimization/compilation steps that happen in the kernel component -- optional, since this layer may not be your target, 4) GPU does your work for you.
At most, you're talking 3 layers to compromise. Compare to real-world vulnerabilities against other parts of the browser (see also: Pinkie Pie) where you're involving dozens of steps, and suddenly this doesn't look too difficult. The tough part is that it requires a significant amount of domain specific knowledge, but I'm certainly not the only one with it.
WebGL, as awesome as it is, is a security risk. It's one caused primarily by the fact that GPU vendors have never had to care about security along these lines before. It will be solved eventually, but it's damn sure not solved now.