Slashdot Mirror
WebGL Poses New Security Problems
Julie188 writes "Researchers are warning that the WebGL standard undermines existing operating system security protections and offers up new attack surfaces. To enable rendering of demanding 3D animations, WebGL allows web sites to execute shader code directly on a system's graphics card. This can allow an attacker to exploit security vulnerabilities in the graphics card driver and even inject malicious code onto the system."
Now that we finally have sandboxing in browsers they want to let any website run directly code on your hardware. Insane! Just forget the WebGL stuff. Silverlight has direct support for XNA which handles it everything better and safer anyway. Are we also supposed to write WebGL games with notepad? At least XNA games can be written with a solid IDE like Visual Studio. Not only that but the games also work on Xbox360 and mobile phones without such a major porting. What a developers dream...
Leave my hardware alone and secure!
I mean what could possibly be dangerous about allowing random websites to run hardware level code?
You can dedicate hundreds of threads to high-volume malware, while freeing up your CPU to maintain a smooth phishing experience!
An attack based on "exploit security vulnerabilities in the graphics card driver" seems less likely using the FOSS graphics drivers. I'm not saying they can not be exploited, I'm just saying that this makes me feel somewhat safer than I would feel if I were using the closed Binary Blob drivers.
9/11: Never forget it was a false-flag operation
WebGL is a Javascript expression of OpenGL ES 2.0, the same OpenGL edition that appears on Apple's iOS and recent versions of Android. OpenGL ES 2.0 is essentially OpenGL 2.0 with the fixed function pipeline removed. This reduces the size of the API substantially.
Some may remember the little ARM11 based computer that appeared last week supports OpenGL ES 2.0. OpenGL ES 2.0 is also the choice of Wayland developers. There seems to be a big convergence happening around this particular edition of OpenGL due to embedded GPUs
WebGL is manifested as a context of a HTML5 canvas element. Javascript has been extended with new data types to provide aligned, dense arrays for loading vertex attributes into the GL. WebGL allows vertex and fragment shader code to be loaded into the GL.
The end result is very high performance graphics driven by Javascript hosted in a browser. WebGL integrates with the browser in some convenient ways; texture data is loaded from Javascript image objects and CSS can apply 3D transforms, for example.
WebGL has been supported in experimental form by Webkit and Mozilla since late 2010. Opera also supports WebGL. Microsoft is no where to be found.
Operating systems compromise security for the sake of GPUs. Obviously, exposing graphics subsystems to inevitably malicious code will get machines compromised. I think Google, Mozilla, et al. should adopt the 'no-script' paradigm for this stuff and require the operator to explicitly enable WebGL content case by case. The graphics subsystem will never prioritize security over performance so securing these code paths well enough for public exposure will never happen.
It would be nice if they gave this some thought before millions of people get owned and WebGL gets a huge black eye......
Lurking at the bottom of the gravity well, getting old
Something, that was just put out that undermines the security of something else......I never saw that one coming.
Cannot find REALITY.SYS. Universe halted.
The only difference is this provides access to driver vulnerabilities. But those same unsuspecting users are likely to download random games and run them locally anyway.
The outcome seems surprisingly similar to flash:
This vulnerability (CVE-2011-0609) could cause a crash and potentially allow an attacker to take control of the affected system.
Now that we finally have sandboxing in browsers they want to let any website run directly code on your hardware.
As opposed to what?
Keep in mind that sandboxing is a way to deal with websites having direct hardware access. That's how they can do NaCL safely.
Silverlight has direct support for XNA which handles it everything better and safer anyway.
What's "better" or "safer" about XNA? Never mind that nothing's stopping you from porting frameworks to this anyway -- having a lower-level standard means that, ultimately, you can have something like XNA, and others can have other things.
Never mind that XNA doesn't have a particularly good OpenGL implementation, and that Silverlight is barely an open standard as it is. Why on earth would we go from one proprietary plugin to another, when we can just use the native, open Web?
Are we also supposed to write WebGL games with notepad?
If you like. Or with TextMate, or with Eclipse, and you've got tools like Firebug and Chrome's Developer Tools.
Never mind that Chrome is actually cross-platform and free-as-in-beer, and Chromium is open source. Why should I have to boot Windows, let alone pay a massive licensing fee, in order to use a giant, clunky IDE just to build a web app?
I remember developing HD-DVD using Visual Studio. It was the best tool we had, which was really sad -- no way to make that work in Eclipse, and no good way to debug otherwise. Never mind that the whole thing would only work on XP -- not Vista or 7. Do you have any idea what a relief it was to start doing web development again, where I could have my choice of tools, OSes, and working environment, instead of being stuck on an admin account in XP?
Not only that but the games also work on Xbox360 and mobile phones without such a major porting.
Know what else mobile phones have? The web. And it actually works natively, as opposed to attempts to get XNA working on Android and iOS, which are kludges running on top of Mono.
Don't thank God, thank a doctor!
I raised this concern with Quake Live, but was quickly shut down by people. Nobody wants to listen to the possible security holes in something they want to ram through at all cost. Forgive my tone if I'm a little annoyed hearing this. Sometimes you want to be wrong about something, but now I have been proven correct, I'm annoyed with myself.
The dangers of knowledge trigger emotional distress in human beings.
So they're saying that enabling shader code execution allows web sites to exploit hypothetical vulnerabilities in the graphics driver? How's that different from saying that enabling Javascript code execution allows web sites to exploit hypothetical vulnerabilities in the Javascript interpreter?
Browsers can statically analyze shader code if need be, even if that means only allowing a subset of instructions.
They got BSODs by 'overloading' GPUs. By doing what, continuous high-stress activity? In which case, surely they should be sufficiently ventilated etc. isn't that the real issue - surely it's not possible to kill GPUs by just making them a lot of work? Imagine if CPUs did that, we'd be pretty screwed by now
If they don't mean high-stress/high-throughput activities, what do they actually mean - overloading them with textures or something?
GPU shaders have no access to main memory so where is the attack vector ?
Can anyone remind me why we're putting EVERYTHING in a web browser anyway?
You keep using that word. I do not think it means what you think it means.
Mozilla Firefox before 3.5.16 and 3.6.x before 3.6.13, and SeaMonkey before 2.0.11
I remember the days when folks predicted JavaScript would expose surfer's computers to viruses.
Not only that but the games also work on Xbox360 and mobile phones without such a major porting.
Know what else mobile phones have? The web.
Xbox 360 doesn't have the web. What do you recommend to get a game ported to a console?
Relegate yourself to Microsoft's little vertical romper room if you want.
If I ignore Xbox 360, I relegate myself to single-player and online multiplayer, as opposed to local multiplayer within a household. PCs can be connected to HDTVs and gamepads, but the majority of people appear unwilling to do so.
Javascript is a language for use on the Web. You know, hypertext: text, links, and images.
Another word for "images" is "graphics".
There's no reason ever for this to have access to your GPU.
"GPU" stands for "graphics processing unit". You appear to claim that a language for use in a graphical environment shouldn't have access to capabilities exposed by a graphics processing unit. Can you clarify?
Are people clamoring to play processing-intensive 3D games in a web browser?
Yes. Otherwise, Adobe would not have added rudimentary 3D capability to Adobe Flash.
If Flash breaks, I can either disable it and wait till Adobe gets off their lazy asses and fixes it, or leave it enabled and thus be vulnerable.
Or switch to Gnash and Moonlight, and fix any deficiencies in your own copy the same way you claimed that you can "fix [WebGL] in your own browser". Ultimately, your complaint appears to be that you haven't had the opportunity to help Gnash and Moonlight become viable.
Are you talking about theory or practice? As I understand it, in theory, HLSL and GLSL are not hardware-specific because they have reference software renderers that can run on a CPU, albeit with drastically reduced performance. Even in practice, I understand that Intel's GMA offloads vertex and geometry shading to the CPU, for example.
and how can we have fun experimenting with this on our LANs? This would be perfect for pen testers to play with.
Which they had already written for WebGL.
http://mxr.mozilla.org/mozilla-central/source/content/canvas/src/WebGLContextUtils.cpp#101
At least then users have to click ok before trusting a site, in a similar fashion to location data.
And hopefully that check will be strongly worded.
Personally, I'm glad I run NoScript
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
What's also funny is I remember discussing precisely this attack method a few weeks ago w/ webgl folks.
Thought at the time it'd be a bit slower than the end result, in terms of image extraction.
Also joked about combining it with a webgl game to keep the user occupied, where their clicks on the "red ball" or "blue ball"
would steal more pixels.
Speed up the attack while keeping them occupied.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
I doubt this is going to be a major cause of future security problems.
As far as I'm aware, WebGL is only allowing shaders to be specified in GLSL which is a pretty high level shading language. Obviously there's no such thing as pointers, and unlike something like javascript there's no interaction with complex objects. Shaders form a very clean and thin interface, basically just being a bunch of floating point vector operations. The only complex objects you're really going to interact with is various texture samplers.
It's easy to make a dangerous bug in a javascript interface to a complete HTML DOM object (or whatever else you can do in javacript these days), it's much harder to make a dangerous bug in a function that calculates a dot product. Sure, shaders are more complicated than that, but you get the drift.
about:config
webgl.disabled = true
-molo
Using your sig line to advertise for friends is lame.
The natural progression of "web as platform" is to (safely) expose your hardware to web-based applications, for your benefit. Vendors who currently enjoy being the gatekeepers of various walled gardens (I'm lookin' at you, AppleSoft) are going to try to stall this progression as long as they possibly can, as it threatens their cash-cow businesses. I very much doubt the handful of web platform vendors integrating WebGL right now are going to allow it to run amok in the same way that ActiveX and Flash have over the last decade.
The "user" have no clue about what no-script is. He/She will just see this as some hinder.
Every time you fail to properly sanitize your inputs, a kitten dies.
Hacking using shaders is simple when using a fixed hardware/driver like on 360.
But is not simple todo using different browser versions, different hardware, and different drivers versions.
I would like to see a proof of concept that works on several platforms/browsers/driver versions.... Good luke LOL
With Mesa and at least, Radeon drivers all commands written to GPU are checked by a parser to prevent certain violations from occurring? The CP (Command Parser) in the Mesa/Gallium3D driver checks all commands written.
Everyone wants a Tux in their life.
For the most part this is a lot of security handwaving.
While the GPU itself can do DMA and whatnot, shaders don't have access to any of that. If a shader can access texture memory that hasn't been assigned to it *in certain browsers* then it sounds like a bug in the browser or the browser's WebGL plugin. Being able to "overload" the GPU and blue screen the computer sounds like Yet Another Windows Bug.
A shader isn't just some arbitrary binary blob that gets executed directly by the GPU. Even native programs can't do this. You provide the driver your shader source code, the driver does the rest. It's intentionally a black-box process so that the driver can optimize the shader for the GPU and not force a specific instruction set or architecture onto GPU designers. Thus allowing the underlying GPU design to evolve, possibly radically or in unforseen ways, without breaking compatibility.
Furthermore, a shader can only access memory via the texture sampler units, which must be set up by the application. If the WebGL application (which is just JavaScript) can set things up to access texture memory it isn't supposed to be able to, the problem is with the WebGL and/or HTML5 implementation, not the concept of WebGL or the GPU driver.
This is overstated and inaccurate headline. A large area of harm can come from a software application accessing memory space which is a hardware adapter mapped into address space of the app, and manipulation of pointers and so on. This is a issue with C level programming where you have direct access to memory addresses and pointers. A javascript implementation of WebGL does not offer access to OpenGL functions by addresses or pointers to the functions at all. Instead it should use a dispatch table below the javascript environment. JS is thus isolated from direct access to hardware and IS NOT using hardware addresses in any way to access functions.The WebGL program can only therefore access the functions via that dispatch table. There are still possible issued with problems with the OpenGL API itself that may need to be addressed for safety. However, direct access to video hardware by a Javascript app is out of the question, it should not be done, and should not be allowed in a Javascript environment. the Javascript is a sandbox and does not provide direct access to memory address space, system calls or other such things. if security is a concern, due to Hardware faults that could be triggered by sending a series of OpenGL commands, the web browser can be configured to use software renderer instead of the hardware rendering, or selectively block that series of OpenGL commands in some way. If there are significant problems with hardware rendering, that may be sometjhing that may have to be considered as a default option. this is something that can affect all applications that are used over a network including gaming applications, since, even a gaming app that sends abstracted updates such as "soldier moves forward 200px" can trigger OpenGL calls in a predictable way. However, these nor WebGL should not expose the graphics hardware directly to Javascript or the network protocol, nor the address space, only OpenGL functions can be called by some sort of token or symbol which is contained within the sandbox environment and does not directly referfence a memory location. Those OpenGL functions are used by a wide range of different network applications, so this is not a problem particular to WebGL.
I am a web rendering engine developer so I have an interest in making sure these things are safe. If necessary we will software render by default until we can be sure about safety with direct rendering. Furthermore this is not a WebGL problem,s, these are bugs in OpenGL itself. There are software rendering workarounds. So this will not affect the availability of WebGL.
I do support WebGL since it will help the web environment compete against Flash.
12 years later, gaming in a web browser is still a bad idea.
Browser gaming offers on-demand zero-install cross-OS deployment of video games over the Internet. It also offers sandboxed execution so that a game doesn't end up with permission to overwrite or disclose all of a user's documents. What better solution do you have that offers both of these features? Would you recommend Java Web Start or Adobe AIR?
I fail to see how it is specific to WebGL, all web content is dangerous if you take it this way. Lets say, if you had a buggy PNG decoder, that could be exploited with a specially crafted PNG image which is posted on the site.
He's right. Using WebGL, you do not directly upload executable code to the GPU. You send textual shader programs, which are Just-in-Time compiled by the OpenGL driver into hardware instructions. This is pretty much exactly what modern JavaScript engines are doing already.
Now it is true that things can go wrong in this translation stage. A JavaScript engine can have a bug that allows arbitrary code execution, and so can an OpenGL driver. So adding WebGL increases the amount of code that can have security-relevant bugs, but so what? This happens every time you add a new feature. Flash or Silverlight are no different in this respect, and neither is JavaScript itself for this matter. If you're really that paranoid, you should already be browsing without JavaScript enabled.
well, my ps3 runs firefox4
I'm assuming that your PLAYSTATION 3 console is running Firefox under Linux under Other OS under pre-3.21 PS3 system software. (Please correct me if I'm wrong.) But new PS3 games require a PS3 with post-3.21 firmware. This means people who still run a PS3 with pre-3.21 firmware aren't buying new PS3 games; they can be considered closer to the PC market than to the PS3 market.
Or has Sony replaced NetFront in the PS3 system software with Firefox?
Moonlight on Android preview.
Also... ExEn
>> Suck it, Windows users.
Sounds like you're telling Win users to suck upon the perfected formed, pert ... um fragments of their lovely detailed (and d^Hphong shaded of course) ...uh models. I don't see the issue.
response from WebGL PR: Now is the time to have a harden member lead us out of the Uncanny Valley (of the Dolls)!
Atlas Shrugged : Thematic Story