WebGL Security and Microsoft Bullshit


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 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.

  • Robin Lee

     Only to people who aren’t dicktrolls.

  • Robin Lee

     Only to people who aren’t dicktrolls.

  • Anonymous

    I respond to reason…maybe you should read Justice Brandeis’ 1927 famous brief in the Whitney v. California case.

  • Anonymous

    I’m not concerned about a lot of things till it encroaches my area, too. Don’t try to deflect from the topic or issue.

  • That’s certainly possible. Doesn’t matter to the central point though. They can’t have it both ways. As a company they can’t claim they won’t ship something with access to the GPU because it’s insecure while at the same time shipping something with the same access to the GPU and allowing 2 other technologies with the same access to the GPU.

  • Anonymous

    If you don’t understand, then you’re lost.  Consider your time completely wasted, on everything.

  • Anonymous

    This is the same thing they did with Java.  Microsoft takes security seriously now, and if they can’t control the environment, they can’t control security.  So they’d rather not support something that they find full of holes and can’t get fixed.  Sorry to you negative heads, but this is a very good step.  Some have found similar holes in Silverlight, but guess what, those will get fixed!  This GL bullshit will probably not get fixed any time soon, if at all.

  • Terry

    Thank You brons for injecting sanity and logic into the conversation. And Gregg good rational and fact-based account about WebGL and how other comparable tech uses it. We need more rational fact-based debates in the interwebs nowadays. 

  • it’s worse than that. You don’t even need shaders. Just draw a lot of large polygons .

  • Ssh

    teh issue about wbgl might be like this:

    i am pretty sure you willl understand what i want to show you 🙂

  • Thanks, I thought this was an interesting read. Do you have any specific evidence that ContextIS were hired by MS?

    I’ve not looked at the way in which SilverLight and WebGL expose graphics acceleration, so I can’t really comment on the article as a whole, except to say that  “exactly the same features” might not be exposed in the same way, which would make a difference to the level of risk the feature poses.

    But I can comment on this paragraph:

    “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.”
    Malicious Code in a browser renderer tab can (on Windows at least):

    * Access the network
    * Call Kernel Interfaces (IOCTLs – which may expose graphics drivers)
    * Send Key and Mouse Events to NPAPI plugins (like Flash)

    Also, it is not prevented from accessing any files, but it can only access files as permitted by the broker.

    Lastly, the GPU processes itself is not sandboxed, but it will be at some point in future and WebGL support may make this more important.

    Let me know if you want any references to back up these comments.

    – Tom Keetch (@tkeetch:disqus )

  • As a web developer I couldn’t care less about WebGL. As a user I don’t care much about security on this level because I don’t think many attacks come from actual vulnerabilities in drivers and such.

     As a gamer I hope WebGL dies a horrible death. I don’t want thousands of talanted game developers going out to create 3D Farmville. I want them to create Rage, Crysis 2, CoD and the likes. I believe everyone who supports WebGL hates me that’s why I hate everyone who supports WebGL

  • First of all, crashing your driver != insecure. You are not able to execute code by crashing your driver.

    Second of all, I never claimed you couldn’t DOS your machine with WebGL (which is what your page demonstrates). I claimed that Microsoft is releasing the exact same tech in Sliverlight5 which has the same problem. Click the link in the post and see your machine have the same issue with Silverlight5. They can’t claim they won’t ship something that has this problem on the one and while on the other shipping something that has this problem.

    I’m happy to provide you with examples from Flash 11 and Unity3D as well.

    3rd. I pointed out, except for being annoying, what’s the point of crashing your driver or DOSing your machine from the point of view of someone trying to be malicious? If you go to a site and it crashes your driver you won’t go back to the site. That’s not helpful to someone who wants to be malicious. They want read your files or steal your passwords. WebGL exposes nothing that makes that possible.

    4th, as was pointed out in the article. Windows is currently the only OS that handles this case by resetting the driver. OSX, iOS, Android do not. As I also stated above the Khronos group is working on resolving this issue. They’ve already gotten driver vendors to release extensions to handling this in Linux. At some point Apple will as well.

  • Anonymous

    “I believe everyone who supports WebGL hates me that’s why I hate everyone who supports WebGL.”
    What a stunningly inane outlook. I just love the logic of “All developers must work on the things that *I* want, and any developer who wants to build games on the web is a developer who would otherwise be working on Crysis 27.” This makes precisely zero sense.

    If you don’t want better games on the web, then just ignore them. But there are those of us who would like to have the technology to create more interesting games than Farmville, that are easily accessible to a wider audience.

  • Adam Hoka

    “I claimed that Microsoft is releasing the exact same tech in Sliverlight5 which has the same problem.”

    Unfortunately I get this: The version of Silverlight you have requested is not yet publicly available.
    So we are currently talking about a bug in a beta versions software, it “may” be fixed in the final version. Let’s hope for it and don’t judge an unfinished product. With WebGL we are talking about a _released_ specification, which is already included in actual products. And it is proven to be defective by design. Thats a slight difference…

    “First of all, crashing your driver != insecure. You are not able to execute code by crashing your driver.”

    We heard this crap from OpenBSD, so I don’t want to really comment why is this a big bullshit bingo. 😉

  • The problem is we’ve proven that any access to the GPU allows this DOSing feature. It doesn’t matter what Silverlight5, Flash11 or Unity3D do. You need very minimal features for this DOSing to happen. The features they all claim to expose are plenty. If any one of them finds a solution that same solution can be applied to all of them. Hence why Microsoft should be helping to find a solution that’s better than just resetting the driver since they needed it as much as anyone.

  • I don’t blame the game devs. I blame the “everything should be web” mafia lead by Google. My fear is not that I won’t be able to ignore Farmville (I am doing pretty good job at that right now). My fear is that one day I may need to ignore things in the Quake or StarCraft franchises

  • Jeff Carr

    Isn’t it just that your javascript example is defectively written? So it are tries to make 100000 thingamaggigs (numQuads). Change numQuads to 100 and it doesn’t spin the cpu/crash. What’s so impressive about this? It seems more like: “oh look I can write javascript that will suck CPU/crash”. Who cares.

  • Anonymous

    There’s a vast difference between “we’d like to be able to do most things on the web” and “everything should be web”. No one’s trying to take your phone, game console, laptop, or desktop away, nor stop anyone from building games for it.

    Would you refer to Nintendo as the “everything should be Wii” mafia? In addition to the “hate” and “mafia” comments, maybe you could throw in a nazi reference for a trifecta? 🙂

  • Anonymous

    I think you’ve completely missed the point. Silverlight/DirectX abstract much further from the drivers than OpenGL does and there is even a proof of concept in the Khronos FAQ section that uses WebGL to execute arbitrary code by a buffer overflow on the GPU. And there is a proof of concept that reads graphic rams to reconstruct what websites you’ve visited by exploiting WebGL. Even John Carmack, quite the OpenGL evangelist, has publicaly voiced on his twitter stream that he agrees with Microsoft’s assessment (now that really is quite something). DirectX does more abstraction from the driver than OpenGL and DirectX is in such a way part of the OS that it receives automatic updates, (which MS can’t provide for the OpenGL API/drivers because it’s provided by 3rd party vendors).  

    A lot of people have been screaming ‘OH MS not AGAIN’ or whatever, but MS actually has quite a strong argument here and many industry professionals (like John Carmack) agree. Even Khronos agrees there are security issues, (even before MS’ accusations) but they are trying to downplay it.

  • 1) There is no proof of concept executing arbitrary code in the Khronos FAQ.
    2) The exploit reading vram was a bug in FireFox, not in WebGL.
    3) WebGL runs on DirectX on Windows
    4) Silverlight 5 does NOT provide more abstraction than WebGL

  • Anonymous

    I didn’t realize how much direct access WebGL gave you to the hardware level. This is absolutely a problem. In order to get to this hardware level in Silverlight, you have to run a PInvoke. Silverlight WILL NOT LET YOU USE PINVOKE IN THE BROWSER. In order to do a PInvoke operation in Silverlight and get this level of access, you have to install the application OUT OF BROWSER…essentially, as a desktop application.

  • Anonymous

    Silverlight 5 does provide more abstraction that WebGL in the context of when you’re running it in a browser (see my post below). Also, this doesn’t just get pushed out while it’s still experimental. You have to go and explicitly download it. If you want to install it as a desktop app, you have to explicitly do that too and you have to explicitly give the application elevated permissions. You should try it sometime 🙂

  • You don’t need to call PINVOKE. This Silverlight5 sample shows all the features needed to do all the things MS claims are supposedly insecure


    It shows creating buffers, creating textures, loading shaders. Those are the only features WebGL exposes. It exposes them at the same level as seen here in Silverlight5.

    There is no call to PINVOKE and there is no more or less abstraction in the 2 APIs.

    VertexShader.fromStream is the same as gl.CompileShader()
    new Texture2D(…) is the same as gl.texImage2d(…)
    new VertexBuffer(…) / vb.SetData is the same as gl.createBuffer(…) / gl.bufferData(…)
    graphicsDevice.DrawPrimitives(…) is the same as gl.drawArrays()

  • Anonymous

    That’s using the High Level Shader language and using pre-compiled hlsl files…I guarantee you PInvoke is used to compile those shaders – In Silverlight 4 you can use HLSL’s – it’s like working with a writeable bitmap. There is a HUGE difference between VertexShader.fromStream (which is reading from a bit stream that uses the basis of a pre-compiled hlsl file and gl.CompileShader() which I’m pretty sure is using a PInvoke behind the scenes) the point is you don’t have access to do something like THAT in Silverlight 5 unless you’re out of the browser (no longer a plug-in but an acctual application) and then you’ve already been notified that you’re giving elevated trust to the application and have agreed to that…. it’s the same as playing a game you installed from a DVD at that point.

  • Asdf

    I already have to turn off cookies, disk caching, password saving, search
    suggestions, Javascript, Flash, Java, Quicktime, and Silverlight to have a sane
    browsing experience.

    Thank you for yet another idiotic thing I will have to go disable by default
    in my browser.

    Maybe some people need to get it through their heads that some of us DON’T WANT a bouncing dancing flashy animated bullshit web that assaults my machine with mobile code, ads, drive-by attacks, spam, and malware every time I just want to read the god damn news.

    I am annoyed that I had to turn on Javascript just to post this comment.

  • Rant or not, IE, whatever number you put at the end of it, puts a huge number of hours on development.

  • Alex

    You are right, and they have the same reasons than Google to make everything running inside a browser and “lock-in” developers with web tech so Google can get money from Ads and other cloud based services. Same reason why Apple try to lock-in developers in their iOS. Google, Microsoft, Apple, same thing. Anyway, I think that web is “less-evil” but still…

  • Guest

    Problems Solved ??  ……or not ?? 
    I know this thread is old but am hoping someone will comment about iewebgl.com


  • Seljo Myeri

    sounds like a rant to me, since Silverlight is also cross-platform… I don’t see the lock-in argument.  Now, might grant you MS could be disingenuous about the security concerns, given that Silverlight is similar.

  • Tom

    Yea, microsoft is just telling bullshit.. that why the security problems are taken in consideration in the new WebGL 1.0.1 specification. Even Microsoft was working on that specification. Sorry greggman, but you failed miserably.

  • Shell

    An amount of FUD it could be, but still, even now months later, the OS-crashing WebGL bugs still bring down the entire OS in both Chrome 15 & FireFox 8. I can’t think of any other browser-based scripting that can bring down my entire machine.

  • I pointed out that was a problem for WebGL as well as Sliverlight 5 and Flash 11 and asked Microsoft for help.

    The FUD is that Microsoft is dissing WebGL on the one hand and on the other releasing tech with the same issue (Silverlight 5) and also not complaining about Flash 11. It’s that hypocrisy that’s the issue.

  • Joyle

    I think the blog post you link to pretty well proves greggman’s point.  The ‘solution’ to secure Silverlight 5 at this point is to disable 3d by default.  From the linked page:

    By the way, you may experience security errors with Silverlight 5 RTM
    when you want to use the wonderful new 3D feature. In fact, some
    graphics drivers may allow malicious code to execute. That may lead to
    an unwanted hard reset or a blue screen.

  • Hey

    Yes, the solution was to disable 3D (in a way, that regular consumer is not able to turn it on easily, devs are crying about this, google it), so the 3D features definitely become useless on any partial-trust site (which means definitely all internet sites). The single statement of gregman that was valid, is about the inconsistency of Microsoft’s policy. But since MS definitely killed off the 3D feature of SL (on the internet), the policy become consistent.

    We will see if they include WebGL in their new WinJs full-trust client solution.

  • Gabriel

    A title like “WebGL security and my full load of bullshit” would be more suitable.

  • Nothing has changed in WebGL and now Microsoft is shipping WebGL in IE11 and has even posted a WebGL game written by them. Guess that proves we were right. It was Microsoft FUD because suddenly they’ve changed their tune.