WebGL (security) sucks.

[quote:3uuh443s]WebGL - A New Dimension for Browser Exploitation

James Forshaw

Summary

WebGL is a new web standard for browsers which aims to bring 3D graphics to any page on the internet. It has recently been enabled by default in Firefox 4 and Google Chrome, and can be turned on in the latest builds of Safari. Context has an ongoing interest in researching new areas affecting the security landscape, especially when it could have a significant impact on our clients. We found that:

• A number of serious security issues have been identified with the specification and implementations of WebGL.
• These issues can allow an attacker to provide malicious code via a web browser which allows attacks on the GPU and graphics drivers. These attacks on the GPU via WebGL can render the entire machine unusable.
• Additionally, there are other dangers with WebGL that put users? data, privacy and security at risk.
• These issues are inherent to the WebGL specification and would require significant architectural changes in order to remediate in the platform design. Fundamentally, WebGL now allows full (Turing Complete) programs from the internet to reach the graphics driver and graphics hardware which operate in what is supposed to be the most protected part of the computer (Kernel Mode).
• Browsers that enable WebGL by default put their users at risk to these issues.

<img src="http://img560.imageshack.us/img560/3011/webglimg.png">

More here: http://www.contextis.co.uk/resources/blog/webgl/

Here's a video showing the attack in action:

The user goes to a webpage, which silently downloads a remote program (calculator) and executes it, bypassing Chrome's security features.

http://www.vupen.com/demos/VUPEN_Pwning_Chrome.php

I never really liked all the extra stuff they're adding to the web. They are creating countless new attack vectors in the process. :( Anyone remembers ActiveX? lol

Anyway, unless you actually want to see 3D stuff in your browser, for whatever strange reason, you should disable WebGL. In Firefox, you can disable WebGL by typing about:config into the address bar, find webgl.disabled and set it to true. Feel free to google for instructions on how to do this in other browsers. :P Internet Explorer 9 does not support WebGL (good job, IE engineering team!)

Do you think this will negatively affect WebGL adoption? Should it be scrapped and redesigned with security in mind? I wonder how this will affect Construct 2.

No offense to any WebGL fans out there. ;(

You make some very good points in your post.

I'm not a big fan of what's being added to browsers either.

It's almost as if everyone is getting so excited about the potential that they're trying to run before they can walk.

I've no doubt that most of these loopholes will be plugged, along with others that are discovered as we go on, but early adopters should be careful.

The majority of those early adopters will be casual computer users, and they're the ones really at risk because with all the hype behind it, they'll assume it's safe.

Krush.

[quote:3vi55qm5]I'm not a big fan of what's being added to browsers either.

I agree.I always disable the Add ons within my browser.

Is the VUPEN article actually related to WebGL? It doesn't say how they achieved it - it could be done through Flash, for example.

I was in favour of WebGL in browsers because it would basically allow the HTML5 exporter to have feature parity with the Construct Classic runtime - you could have shaders, 3D, tints, mesh distortion, Z elevation and so on, running in the browser. People have asked for this. However, the article about WebGL does raise some very interesting and valid points. I guess it is true graphics card manufacturers never really had to consider the security of their drivers before, so they're caught out unprepared with WebGL.

It doesn't appear you can do anything beyond crash the system or possibly read images cross-domain. There's nothing you can do at a shader level to, say, steal user data, or install or modify files on disk. So the risk seems somewhat limited - much less risky than running an unknown EXE.

I'm also not convinced the risk is exclusive to WebGL: with browsers using hardware acceleration to render HTML, it seems with Javascript and HTML you could "attack" the hardware by creating a page that would take an extremely long time to load, and possibly crash. Also, you could probably "attack" some systems with simple javascript by running something intensive that runs the CPU at 100%. This could cause system crashes or overheat badly designed systems. This is the fault of the system designer, though. It looks like WebGL is "worse" because graphics card drivers tend to be badly written anyway (*cough* *cough*INTEL CHIPSETS*cough* *cough* oh dear me, I seem to be unwell). If you crash a driver through WebGL, it's the graphics card maker's fault. It can and does crash from time to time anyway.

What I guess will happen is browsers might end up prompting you something like "This page wants to display 3D content. Allow / Deny".

That's not so much a problem for an arcade, for example, but would really make it impractical to use for banner ads, site headers and general interactive content.

So for now I guess it's lucky we're sticking with canvas!

When I test the exported content locally on iexplorer 9 (or whatever the default win7 64bit iexplorer browser is, and it pops up a window saying it's blocked running some scripts or activex content... allow or deny..

This concerns me as if it does this for people viewing my project online and it's not just isolated to testing the exported html5 page from a local source.... It will like;y scare users that aren't pc savvy away.

Viruses and attacks these days aren't designed to crash computers, because that wouldn't make any sense, it would be a suicide for that virus. I think these days it's important for viruses to spread and benefit the creator or something that they believe in.

At least, the cross-domain image source problem isn't one anymore on FF & Chrome, since they don't allow it anymore.

The image buffer stealing problem can be stopped by filling the buffer with a pre-made texture, as large as the VRAM, initialised with random values, to prevent "old data" reading via a shader.

Jax - that's unrelated to this thread you've posted in... IE doesn't even support WebGL. The warning is solely because you're previewing locally (on localhost) and should never appear once you publish to the web, therefore it's not of any concern to any users. I'm not sure it even comes up locally in other browsers like Firefox and Chrome.

And wow, this is an old thread from 2011, and I'm not sure I even agree with that post I wrote above any more.

I about had a heart attack when I read Ashley's first post... Then I saw it was from May 2011. Phew.

Jax - that's unrelated to this thread you've posted in... IE doesn't even support WebGL. The warning is solely because you're previewing locally (on localhost) and should never appear once you publish to the web, therefore it's not of any concern to any users. I'm not sure it even comes up locally in other browsers like Firefox and Chrome.

And wow, this is an old thread from 2011, and I'm not sure I even agree with that post I wrote above any more.Thank you for this information,I was not sure as I read on several google results that webgl somehow was related to ActiveX and thought it was related. I now understand the situation thanks again and apologies for digging up this old thread