Microsoft calls WebGL "harmful" | Hacker News Reader

Microsoft calls WebGL "harmful"

blogs.technet.com

32 pointseykanal18 comments

I agree with Microsoft’s assessment that WebGL is a severe security risk. The gfx driver culture is not the culture of security.

~ https://twitter.com/ID_AA_Carmack/statuses/81732190949486592

Carmack goes on to say that he prefers NaCl (as in Native Client) for webgl like applications.

Any thoughts from someone who's more informed than me?

NaCl bindings to HW accelerated 3d share the same issues (like any other technology using GPU acceleration including Molehill, Silverlight or Unity).

Carmack tweeted the same:

"doing GL ES from NaCL is clearly just as dangerous as WebGL"

http://twitter.com/#!/ID_AA_Carmack/status/81767700447236096

In theory, you could do software rendering in NaCl, but that wouldn't produce as good results as GPU, despite NaCl being more powerful than JavaScript (for example SwiftShader DirectX9 SW renderer scores 620 on 3DMark06 on pretty beefed up quadcore [1], my 2 year old notebook GPU scores over 4000).

So the question is not "is WebGL secure?", question is "are benefits of HW accelerated 3d on the web worth the risks?".

To which IMHO the answer is resounding yes. Problems are minor, benefits are major.

[1] http://transgaming.com/business/swiftshader/faq/

As I said in another thread, aren't these security points all applicable to JOGL running in a Java applet? Therefore if they are exploitable, they probably already are being exploited, and therefore implementing WebGL does not add any new attack vectors. Am I wrong?

An interesting question would be "If all these security concerns were resolved, would Microsoft then implement WebGL?". Then, I guess, the answer is still no, because WebGL is based on OpenGL and not DirectX.

Even if JOGL has the same problems, the blame is not theirs anyway as they aren't distributing Java anymore, otherwise you must blame them for allowing OpenGL on Windows too.

     "If all these security concerns were resolved,
      would Microsoft then implement WebGL?"

To me that's irrelevant - Chrome and Firefox combined have enough market share to make WebGL useful.

What is important to me is if they are right, what are the Khronos Group doing about it? Is WebGL really designed for the web?

AND, can it be fixed without relying on companies fixing their drivers or is it a fundamental flaw?

I block Java applets by default, but not JS, and I don't have a way to block only some JS APIs.

Relevant: http://news.ycombinator.com/item?id=2662632

I've posted in the other threads about this but when I read this: "The security of WebGL as a whole depends on lower levels of the system, including OEM drivers, upholding security guarantees they never really need to worry about before."

I can't help but wonder. If those drivers are so buggy, why isn't this a high priority to fix? It would probably be easier for hackers to attack other things due to the wide range of drivers but if the security issues claims against WebGL are real then escalation of privileges on any OS is a question of breaking the GPU driver.

I find that to be a big issue even with WebGL not in the picture.

"I can't help but wonder. If those drivers are so buggy, why isn't this a high priority to fix?"

It will come. Raised concerns are not WebGL specific, WebGL is just exposing things about HW-accelerated 3d to more general public that have been here since always and every GPU 3d technology has to face (problems with drivers, fragmentation of market, very wide spread in capabilities).

People will need to get used to update their drivers (the same as they already got used to update their OS and browsers).

Gamers are already doing this since forever, not because of security concerns but for bugfixes / performance improvements.

GPU vendors are actually pretty responsive, I'm aware of driver hotfixes released just to address problems discovered on releases of particular games (in between regular monthly driver updates).

Yep, it is a pretty big issue.

However, WebGL does make it worse: it trivially exposes local privilege escalations as remotely-exploitable root vulnerabilities. It also does so bypassing a lot of the sandboxing work that browser vendors have done to contain browser vulnerabilities.

Why not use the existing trust model in IE, as applied to ActiveX? Give users the option to trust WebGL on sites like Mr.doob and block it pending the user's explicit permission on untrusted sites.

Because uninformed users don't know and don't care about security warning mumbo jumbo if it means they get to watch their cat video.

ActiveX is generally agreed upon as one of the worst client-side security holes out there. I understand there are compatibility and legacy reasons it hasn't gotten rid of ActiveX yet, but Microsoft would damage its slowly-rising security reputation considerably if they suggested that model to secure a new technology.

It may well be true, but it's a little odd (to someone who has only ever had one windows computer) to hear them say things like "in a way that we consider to be overly permissive" and "relies too heavily on third parties to secure the web experience". Take out web of this, and it's the exact feelings we had about XP security.

Do they have a non-propriety alternative? The closest thing I can think of is WPF, which is based on Directx.

    it's the exact feelings we had about XP security

Well, actually, Linux or OS X security isn't that much better for the end-user, unless you're a sysadmin with some experience and know how to configure stuff like IPTables and SELinux.

Otherwise when navigating the web, security is as better as its weakest links - the user and its browser.

I mean in terms of how many backdoors are left, unpatched, in programs that inevitably have direct access to the internet, and admin rights.

maybe if they had a sane security model for the browser this wouldn't be an issue? I have to believe chrome team is thinking this with how the browser puts each renderer into a sandbox process... but maybe MS doesn't want to do that because of how they've HW accel'ed so much?

Sandboxing builds on top of existing OS functionality to give each sandbox a separate address space and to guarantee freeing of resources on process exit.

The sandboxing code would have to rely on the video drivers ("the OS running on the card") to similarly manage resources on a video card.

Problem with that is that the video card may not support some required functionality or that the driver may be buggy. Top of the line video hardware has a shelf life of say a year. That puts serious pressure on producing drivers fast. In addition, there is pressure to produce fast drivers, as that is what reviewers look at. You cannot get fast reliable drivers soon, so drivers will be buggy, incomplete, etc.

You cannot build reliable sandboxing on top of buggy drivers.

Reply on news.ycombinator.com