7 ms·
Wow, this thread is turning into another security-clueless developer freakout. Microsoft very clearly laid out reasons why they believe that WebGL presents poss
by Locke1689 15y ago
Wow, this thread is turning into another security-clueless developer freakout. Microsoft very clearly laid out reasons why they believe that WebGL presents possible security vulnerabilities. While GPU security isn't my area of expertise, the driver issues seem very plausible. If someone wants to actually address Microsoft's points in this thread then that would be great.
- daeken 15y agoI can also support their claims with some preliminary research I've done. When I have free time, I've been poking at the security of shader compilers -- both the translation that's done in Webkit and the compilers in drivers -- and things are pretty bad. Don't have much to show for it yet (a couple non-exploitable crashes/bugs), but I think future research will prove very fruitful.
- cma 15y agoI don't have a response, but Microsoft supposedly thinks it is securable enough for Silverlight: "With the release of Silverlight 3 Beta 1 GPU (Graphics Processing Unit) acceleration (or hardware acceleration) is now available." I'd like to hear what could make that secure that couldn't be used with WebGL.
- daeken 15y agoI don't know anything about how they're doing this, but I wonder if it has something to do with the bytecode abstraction used in D3D. In D3D, you compile HLSL to bytecode which then gets passed down to the kernel, but in the OGL world you pass source straight down to the kernel. Definitely still risks there, but significantly diminished, and some simple verification in userland would make it next to impossible to get a lot of nasty code down into the kernel.
- Impossible 15y agoMS could (and probably would) write an Angle style abstraction layer that runs WebGL on top of D3D9 or D3D11 anyway, so I think source going to the kernel isn't a big deal. It's possible that because MS has more knowledge of the graphics drivers work in Windows they know about some dangerous security holes that Mozilla, Google, or even Nvidia or AMD aren't aware of, but its equally possible that they just don't want to support WebGL for political reasons and this is a semi-technical excuse.
- rys 15y agoThe D3D bytecode IR generated by the HLSL shader compiler in the runtime isn't verified for security concerns before being passed to the driver, so there's no real extra protection there, so ultimately D3D makes it no harder to lock the GPU than OpenGL (ES in the WebGL case) does.
- johnzabroski 15y agoIt is a completely separate house / separate bed issue. You do not have permission to call Direct3D directly. You can't even do cool hacks like you can in WPF, stealing the Direct3D video feed and writing it to a movie file. Everything is abstracted away by (underpowered) APIs. All Secunia advisories on .NET Framework / Silverlight are presently patched, and the total number is relatively small compared to other technologies like web browsers and Flash. I don't really know enough about WebGL to compare, though.
- SigmundA 15y agoSilverlight 5 is a better comparison, this blog has the details: http://muizelaar.blogspot.com/ http://muizelaar.blogspot.com/
- johnzabroski 15y agoThat blog is trolling. The blog author copied and pasted the material from the blog we are currently discussing, and replaced WebGL with Silverlight. Silverlight is more secure than WPF, too, by the way, and has to be. For example, in WPF there is a very insecure static method that allows you to steal a bitmap of the entire screen! This was one of the first things taken out of Silverlight. If you want to know more about Silverlight security, ask Nick Kramer who maintains the Silverlight security best practices document for Microsoft.
- snprbob86 15y agoIt's the same thing as Safari, IE, and Chrome using the GPU to composite pages: Silverlight is hardware accelerated, but does not expose the hardware acceleration primitives. GL or Direct3D expose more-or-less direct hardware access, which is very different.
- msy 15y agoWell either Google and Mozilla are knowingly shipping insecure code or Microsoft is, to some degree, wrong. Given the history of the organisations in question I'm going to assume Microsoft wrong or not telling the whole story until we hear a response from Moz or Google.
- Locke1689 15y agoThis is an argument from ignorance and, knowing engineers at both Google and Microsoft, I have no reason to believe that the Google engineers are any more competent than Microsoft. I do know that the Google security team is smaller than Microsoft's.
- code_duck 15y agoHence the 'not telling the whole story' part. Would Microsoft play politics with something like this? Not saying that's the case, only that one would have to be silly to think they wouldn't.
- SoftwareMaven 15y agoMicrosoft has the perspective of the entire OS from top to bottom. Google and Firefox have the perspective of their respective applications. Given the concerns Microsoft is voicing (and they aren't the first to voice them) are well below the application itself, I tend to trust Microsoft more on this one.
- pmjordan 15y agoWhat about Apple? They're clearly working on WebGL support for Safari. They have at least equal insight into the whole stack, considering the ship the GPU drivers with the OS. Then there's XNA in Silverlight. If they believe in the security of that, why not build WebGL on top of it? Probably because they're in direct competition with one another, and Microsoft wants Silverlight to win.
- deleted 15y ago[deleted]
- andrewcooke 15y agothat's not true. most comments agree with you. [edit: and even if it was earlier, only a couple are anti-MS in total]
- Locke1689 15y agoNot when I posted the comment.
- AshleysBrain 15y agoHas JOGL in Java web applets always had these same vulnerabilities? Is JebGL (http://code.google.com/p/jebgl/ http://code.google.com/p/jebgl/) also vulnerable to the same points? Should Microsoft stop supporting Java applets for the same reason?
- snprbob86 15y agoShaders are the big vulnerability I know of. Any game developer will tell you: It's pretty easy to accidentally craft a shader that will totally stall particular GPUs, taking down the entire windowing environment, if not the entire system. With malicious intent, shaders are a giant gaping DoS attack waiting to happen. Beyond that, the shader compiler backends are supplied by third parties because they generate hardware specific opcodes and optimizations. Considering how poor nVidia and ATI's drivers have been historically, do you really trust them to create secure compilers? In theory, Microsoft could implement a subset of WebGL without shaders, but I'd rather it not exist than be crippled and unusable. There are probably several other potential vulnerabilities I don't have firsthand experience with too. All that said, I think that Java applets & JOGL already expose this attack vector.
- spullara 15y agoThose, like activex controls, require the user to agree to install something that can do whatever to their system. WebGL would be available to any web site.
- m_eiman 15y agoThat should be easy enough to duplicate, just make the feature one of those "Site X wants to use WebGL. [Allow] [Deny]" things. It would make it useless for ads and such, of course, but it seems that most people want to use it for games. Might be workable.
- nodata 15y agoThis is not a solution because a user would not know how to answer that question. We don't want ActiveX all over again. The solution is to address the problems in the article.