I don't see why more people don't realize, WebGL is a prime Microsoft threat and the key to moving away from the MS Windows monopoly. That's why Microsoft has done so much work to try to scare people away from WebGL (by sponsoring 'security research' and creating FUD content on Wikipedia (seriously, look at the history of that article, the person who created the whole 'security' section on WebGL has an ip that originates right next to Microsoft headquarters, and the 'security research' is done by a Microsoft shop)).
What the Opera, Webkit/Safari/Chrome, Mozilla teams should focus on is getting mouse capture and WebGL uniformly supported and turned on across browsers and one or two well-hyped and playable 3d first person games. Any industry player who has money and wants to oppose Microsoft should put money behind big WebGL game releases and hype for such.
You get that working across browsers and push that and things like Google Docs, EditGrid, ethercalc, Zoho Creator, LibreOffice etc. and you will see WebGL games starting to take down PC games sales and Office alternatives hurting Windows/Office sales.
Anyway, please give the people in charge of those programs and funds a link to this explanation if you know anyone like that.
"Doom was developed on NeXT workstations, under the NEXTSTEP operating system.[6] The Doom game engine was programmed in C, and the editing tools were written in Objective-C. The engine was first compiled with Intel's C compiler for DOS, but later Watcom's C/C++ compiler was used" [1]
John Carmack is nothing if non-partisan when it comes to tools and platforms. Most everything he wrote was reasonably cross-platform C until id Tech 4, released in 2004.
I'd say Carmack has zero years invested in C++ programming for Windows games. He instead has decades invested in making cross platform game engines written in a variety of C-based languages.
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.
To give an example: On my home pc I have the snapshots of Opera running with hardware acceleration and WebGL enabled: No problems. A few minutes ago I've installed Opera 12 on my work pc and tried the same. Afterwards I couldn't start Opera anymore and had to reset the options in the config file (AppData\Roaming\Opera\Opera\operaprefs.ini if anyone needs to do the same; EnableWebGL and HardwareAcceleration are the keys).
So: Yeah, it's still a bit buggy at the moment (probably hardware compability issues). I've already send my bug report, hope they fix it soon.
This is a real shame, especially for HTML5 games. What's even worse is hardware acceleration on the 2D canvas appears to be disabled by default too, so HTML5 games in Opera 12 on a powerful desktop will run slower than an iPad or iPhone, because they have hardware acceleration. Looks like Opera 12 is a no-go for gaming.
I don't see why more people don't realize, WebGL is a prime Microsoft threat and the key to moving away from the MS Windows monopoly. That's why Microsoft has done so much work to try to scare people away from WebGL (by sponsoring 'security research' and creating FUD content on Wikipedia (seriously, look at the history of that article, the person who created the whole 'security' section on WebGL has an ip that originates right next to Microsoft headquarters, and the 'security research' is done by a Microsoft shop)).
What the Opera, Webkit/Safari/Chrome, Mozilla teams should focus on is getting mouse capture and WebGL uniformly supported and turned on across browsers and one or two well-hyped and playable 3d first person games. Any industry player who has money and wants to oppose Microsoft should put money behind big WebGL game releases and hype for such.
You get that working across browsers and push that and things like Google Docs, EditGrid, ethercalc, Zoho Creator, LibreOffice etc. and you will see WebGL games starting to take down PC games sales and Office alternatives hurting Windows/Office sales.
Anyway, please give the people in charge of those programs and funds a link to this explanation if you know anyone like that.