WebGL Security and Microsoft Bullshit 2011-06-21

Disclaimer:

1) I work at Google on Chrome 2) Nothing I say here represents my employer in anyway. This my own opinion.

It's frustrating to see how bad Microsoft can really be. I'm one of Microsoft's biggest fans. I still think Windows7 is better than OSX or Linux⭐️. I play more XBox 360 games than any other console. I was hopeful for Win7 Phone and am hopeful for Windows 8. I was on Microsoft's side in the Java lawsuit, the Internet Explorer lawsuit and several others. I think Visual Studio's debugger is way better than anything I've used on OSX or Linux. I think C# is way more awesome than Java. I was really happy when they started IE9 development and started actually competing.

So imagine my disappointment when I start seeing the FUD from Microsoft about IE9 vs other browsers. Cherry picking benchmarks, cherry picking conformance tests and generally basically lying.

The latest FUD is Microsoft's claim that they won't support WebGL because it's insecure. They might have a little more credibility if they weren't promoting a technology, Silverlight 5, that provides the EXACT SAME FEATURES.aspx) with all the same issues. They can't have it both ways. Either it's possible to make this tech safe or else it's not. If it is possible to make it safe in Silverlight 5 then it's also just as possible in WebGL. If it's not possible to make it safe Microsoft would have to come out and say (1) They are removing GPU access from Silverlight 5. (2) They are banning Unity3D from running in IE since it also provides access to the EXACT SAME FEATURES. (3) They are banning Flash 11 from running in IE since it also provides access to the EXACT SAME FEATURES.

Since they have done none of these things then we know with 100% certainty that their claims are self serving FUD meant only to try to scare people into using IE on the one hand while exposing the exact same feature set with the exact same risks (according to them) on the other.

It's even more telling that Microsoft hired a firm, ContextIS, to create this bogus FUD so they'd have someone to hide behind. It's pretty convenient that only a few minutes after ContextIS's latest post Microsoft already had a well manicured response. If ContextIS had any credibility they'd be posting about the same issues on Silverlight5 (warning: might crash your machine), Flash 11 and Unity3D.

The sad truth is Microsoft has a vested interest in spreading FUD about WebGL. WebGL enables features that make IE9 and IE10 look like crap. Amazing 3D demos. Even 2D, for example the Facebook JSGameBench got a 4x speed up when switching from 2d canvas to WebGL.

Microsoft has never supported OpenGL which is what WebGL is based on. Instead they have their DirectX API. The DirectX API is great but the #1 reason Microsoft doesn't want to support anything based on OpenGL is that it robs them of some of their lock−in. You see, if you program an application using DirectX for 360, DirectX for Windows, DirectX for Silverlight or DirectX for Window7 Phone, well, you're stuck on those platforms. Want to port to OSX or iOS or Android and you're out of luck. You have to re−write a bunch of your graphics code and shaders.

On the other hand, if IE supports WebGL then more and more programmers will get use to OpenGL like APIs and there will be pressure for Microsoft to start officially supporting OpenGL on their other platforms. THAT is their biggest worry. Not this trumped up security issue that they are oh−so−happy to ignore when it comes to Silverlight 5.

So, Is WebGL a security risk? IMO no more than any other part of the browser. Remember when IE had issues with specially formed JPG images? That was a bug. It was fixed. Problem solved. Remember when IE had issues with specially formed AVI files? That was a bug. It was fixed. Problem solved. ContextIS claims WebGL lets webpages execute native code. Well guess what? JavaScript lets pages execute native code since pretty much every browser, including IE, compiles JavaScript into native code. One mistake on their part and your machine is owned unless the browser provides better defenses.

There are 2 main issues with giving anything access to the GPU

#1) Denial of Service issue.

What is a "Denial of Service" issue in WebGL? It's a situation that happens if a webpage asks the GPU to do something that takes a really long time. Most current GPUs can not multi−task and most OSes need the GPU to do windowing and other things. Unfortunately if a program asks a GPU to do something that takes a long time, say 5 minutes, during that time nothing else can access the GPU. The OS is stuck waiting until that particular task is finished.

We studied this issue in depth at Google and we've proven there is no way you can limit the features of access to the GPU enough to prevent this and still have useful access to the GPU. You can cause this with or without shaders. As long as you can submit geometry to the GPU you can cause this problem.

Fortunately there are solutions. The simplest solution is to time how long the GPU is taking to execute each task. If it's taking too long reset the GPU and kill the page that issued the command. Microsoft Windows is one of the only OSes that currently provides this solution. They should be proud of this. They can basically claim the best place to run WebGL is on Windows. The Khronos group is working to bring similar functionality to other OSes as fast as possible and it may already be available in some drivers.

The other thing about DOSing a machine is if a user goes to "bad−evil−website.com" and their machine freezes how many times do you think they are going to go back? It's a very limited type of attack. It doesn't let you install a virus. It's doesn't let your steal information. All it lets you do is annoy someone until they ignore you. People trying to do bad things to you are going to want to do something permanent, not something that makes you stop going to their site.

Of course it's completely unacceptable if your machine gets DOSed. My only point is (1) there are fixes, Windows already support them and they are coming soon to other OSes. (2) it's not has bad as your machine getting owned. In fact most likely very soon now, if a page takes too long on the GPU it will be marked bad by the browser. If you try to visit it again you'll be warned. Similarly using techniques like "Safe Browsing" we can warn you in advance while we work on providing the real fixes in all OSes.

2) The second issue is whether or not running WebGL is a path for native code exploits.

Here, like everywhere, it's really no different than any other bug. Like I pointed out above if your jpg decoder has bugs it's bad. If your AVI decoder has bugs it's bad. If your font renderer has bugs it's bad.

So what do you do to prevent programs from accessing bugs in drivers? Well, #1 is you test your code and try to make sure it's bug free. Of course you can't count on finding every bug so the next thing you do is security in depth. That's like having a safe deposit box, in vault, surrounded by lasers, surrounded by guards, surrounded by the bank with even more security guarding the bank. If you get through one you have to get through the next and each one making it harder and harder to get through.

So what does Chrome do to keep WebGL safe? #1, like everything in Chrome, we run the webpage in its own process. Even if the webpage could somehow execute native code it can't access files. It can't access the network. It can't access the keyboard or the mouse. In the WebGL case it can't access the GPU. All GPU access in Chrome happens in a separate process called the GPU process. We get 2 big benefits from this design.

The first is that we can parallelize WebGL calls. Once your webpage has issued a command to draw it's free to go do something else while a completely separate process goes off and actually sets up the GPU to do the drawing. For well written WebGL programs, all else being equal, this should make Chrome faster than single process architectures.

The other is that the GPU process validates EVERYTHING!!!! before calling the GPU drivers.

It validates all parameters so a webpage can not pass unknown parameters to the GPU.

It validates the size of all buffers created and all access to them. The webpage can not exploit buffer overruns in a driver. This is part of the WebGL spec.

It validates all indices against the size of all buffers that will be accessed during a draw call. This means a webpage can NOT submit indices that would access data outside a valid range. This too is part of the spec.

It validates that all writing to textures is within bounds. This means a webpage can not submit texture data outside the bounds of a texture.

It validates all buffers, textures and renderbuffers are cleared on creation. This means a webpage can not access data left over from other apps or pages. This is part of the WebGL spec. That Firefox had a bug in this area which has already been fixed. It was a bug in Firefox , not a bug in WebGL.

It validates that every GPU object referenced by the WebGL page was created by that page. If it's not the call is not passed through to the driver.

It validates that the shaders submitted to the GPU use only the minimal features allowed by the spec. That means no dynamic indexing of sampler arrays. It means no infinite loops. There's actually a huge list of features that native apps would have access do that are disallowed by this validation.

On top of all of that we work around bugs in drivers where possible. Examples of some of these bugs.

Some drivers are buggy in that if you give them a shader with an array of uniforms and only access uniforms at the end of the array they'll screw up. We work around that.

Some drivers are buggy in that they crash if multi-sampling is enabled. We disable multi-sampling on those drivers.

Some drivers have bugs with long identifiers in shaders. We work around that by re-writing the shaders with small identifiers and then mapping the user's identifiers to ours.

Some drivers have issues we certain kinds of loops in shaders. We unroll the loops.

Some drivers when asked for an RGB surface will actually return an RGBA surface. We work around this bug as well.

Some drivers don't return the correct format for array identifiers and/or don't correctly identify uniform arrays or attribute arrays as arrays. We work around these bugs too.

I'm sure there are other bugs I don't even remember that we work around.

I think you can see, with all this validation, the odds that a webpage can exercise a bug in a driver become vanishingly small. And finally, if push comes to shove and we can't program a workaround we blacklist the card and/or the driver.

WebGL is taking the web to the next level. Apps like Google Body, Tinkercad and multi-media demos like Ro.me show the way forward.

But don't take my word for it. Here's another opinion by someone who apparently works for Microsoft.

The sad thing is, this is a chance for Microsoft to shine. They are currently the best OS for WebGL. They are clearly pushing Silverlight 5 and even if they decided to pull support for Silverlight 5 there is no way they are going to prevent users from installing Flash 11 which will likely auto install everywhere.

Instead, Microsoft could be leaders here. Since they want Silverlight5 and they know their users will want Flash 11 as well as WebGL in Chrome and Firefox, Microsoft could put even more pressure on GPU vendors to make the drivers awesome! They could add more security tests to their WHQL program. They could require GPUs to handle resetting better than they do. They have the power. Will they use it for evil and selfishly try to hold the web back as they appear to be doing now or will they use their power for good and help take it forward? Imagine if Windows8's HTML5 based UI had access to WebGL!

(*) Maybe it's not better in every way but I still prefer Windows 7 over OSX and Linux most of the time.