Slashdot Mirror
WebGL Flaw Leaves GPU Exposed To Hackers
recoiledsnake writes "Google spent a lot of time yesterday talking up WebGL, but UK security firm Context seems to think users should disable the feature because it poses a serious security threat, and the US Computer Emergency Readiness Team is encouraging people to heed that advice. According to Context, a malicious site could pass code directly to a computer's GPU and trigger a denial of service attack or simply crash the machine. Ne'er-do-wells could also use WebGL and the Canvas element to pull image data from another domain, which could then be used as part of a more elaborate attack. Khronos, the group that organizes the standard, responded by pointing out that there is an extension available to graphics card manufacturers that can detect and protect against DoS attacks, but it did little to satisfy Context — the firm argues that inherent flaws in the design of WebGL make it very difficult to secure."
dupe dupe dupe
Comment removed based on user account deletion
http://www.youtube.com/watch?v=WgbK0ztUkDM&feature=player_detailpage#t=3195s is the video. In short, I asked the NaCl guy whether they knew what they were doing by letting NaCl clients access GPUs directly. His response was that they were doing everything WebGL does to protect the system from malicious code. That's unfortunately not sufficient.
~ C.
Isn't there a point at which keeping your equipment safe from intruders is such a hassle that it's no longer worth even having the equipment? This constant battle to defend your computer is tiresome. I can't imagine not having a computer but this exhausting.
YouTube isn't large enough for you?
http://blog.jprosevear.org/2011/05/13/webgl-security/
Mark Zuckerberg paid for a threepeat. I hear every time WebGL compiles a shader, Orkut emails a thousand SSNs to China.
This seems to be "so, sluggish" to you?
This is nothing more than a scary article about the well-known risk of denial-of-service and using shaders to extract pixels from a remote image -- and the media is slurping it up, using senteces like "run arbitrary code on the GPU ... render an entire machine unusable". Ugh.
It's a completely over-hyped article about something the spec designers have known since day one. The article takes the fact that bad OpenGL drivers can crash a computer to mean a security hole, something which driver vendors are actively participating in resolving for future cards.
I wasted my time reading that whole report a few days ago, and it basically said nothing that wasn't obvious and well-known. The only thing new is they are showing that there is no way to stop GPU code from extracting pixels from remote images embedded in a canvas, which is a real "security" hole, though there's not a whole lot of use for this.
Basically, the extent to which this *should* affect webgl is that they will disallow textures from remote sites -- in other words, it could add an extra annoying implementation step for collaborative spaces that could include models from multiple sites. Also, they might choose to add an Infobar to prevent arbitrary websites from crashing the computer or making it run slowly.
However, thanks to the media slurping this up and using words like "run arbitrary code on the GPU", "render an entire machine unusable", etc., people who read these articles and know nothing about the subject (i.e. idiots) will start to ask browser vendors to turn those features off. But to be honest, I hope people aren't this stupid and "FUD"-y articles like these are forgotten.
Also, the title is plain misleading -- a denial of service attack on buggy drivers should not be described as "Leaves GPU Exposed". A website can not in any way take advantage of crashing a user's computer, and browser vendors will quickly respond with a blacklist patch when they learn of the affected GPU.
If you disagree with anything I said, feel free to comment and I'll explain in more detail why what the article describes are not "security issues" in WebGL.
gpu shaders cannot access main memory. if there are driver errors that cause undesired side effects these should be fixed but the underlying architecture is sound.
can we please move beyond 2D graphics. go whine about real security problems. this is not one of them.
Sure, but you
Neither of these are a "serious security threat" . If you lock up my GPU while I browsing the WWW, not that big a deal. Annoying? Yes. Serious? No.
Talk to me when you can execute arbitrary code as the browser process user (or root).
yeah that's a great opt in trial there -
still, have a look at http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html if you want to get the bigger picture (no pun intended)
Sure as long as you ignore the fact that the vast majority of the content on Youtube is still exclusively only served via flash.
http://blog.jprosevear.org/2011/05/13/webgl-security/
- why hasn't anything decent been made with it?
If you havent already then take a look at http://www.optimum7.com/css3-man/animation.html
its pretty much cutting edge when it comes to combining html5, css3 and js.
Slashdot really should have published a link to this response from Mozilla http://blog.jprosevear.org/2011/05/13/webgl-security/
no not sluggish - it just doesn't work! piss orf.
1. There are a few, but as far as it goes Flash is still LESS resource intensive because it uses the GPU now
2. These are new implementations. Did you really think that day 1 releases would be optimized?
3. Many things have, but when IE has ~60%, and only 10% or so has IE9, there are really only 2 engines writing new HTML(5) features. Gecko, and Webkit. Trident is only putting in safe features because it has to do extended support whereas Webkit browsers (excluding mobile) usually upgrade pretty quick (i.e. they don't fragment). And Gecko's new upgrade system should put it at a really nice path too. So the true answer is, the spec isn't finished and even the parts that are, there aren't enough proper implementations to be able to use it effectively
4. Because there are 4 major engines. Try getting 5 companies agreed on anything. Google, Apple, Microsoft, Mozilla, and Opera. There's other companies like Adobe with stakes in this too. They try to get what their userbase wants the most, while still being secure, and not overwriting features. You don't break the web, and that's a hard thing to do.
5. Those are the people that most web devs are railing against, just like people who introduce only -webkit properties. You enter all or nothing. -ms -moz -o -webkit. There's a battle in CSS going against that. But what you're talking about are SPONSORED sites, as in Google or MS paid or made a contest for people to do that. It's part of the submission to that to get more people to their browser. The people with the biggest browser calls the shots.
HTML is happening, just it's slow to upgrade the world's largest platform. If you don't believe me, ask Brendan Eich. You can't regress, only upgrade, and anything that has regressed, all engines still need to support, otherwise the browser seems broken. And not all the API's are finished, and then they need to go through at least 2 implementations. It's a long process with a lot of companies involved, not just some like OMG WE PATCHED IT.
How the fuck can you comment on HTML5's video performance when your shitty browser doesn't even support it?
YOU "piss orf".
Is it? Everything I can recall for some time can download in h.264 (.mp4) using the Download Helper FF plugin. Then things can be watched in VLC.
That's not exactly in the browser, but it's a workaround to Flash/scripting. So they do serve in something besides Flash.
I wish there was a setting to get Firefix 4 to view that natively. Is there an extension or some other trick?
Maybe a browser ID chnage so it looks like an iPad or something? I know people want to support open codecs, I do too, but can't we have h.264 support that works too?
The key issue is: Putting your data in the hands of those you don't know is a uniformly bad idea. So is giving control of your computer's execution to those you don't know. There is no remedy for this kind of error, either -- once you hand your data over, you have lost control of it, and in turn, you have lost control over the consequences of random third parties misusing your information.
The good news is that we have a broad set of extremely powerful applications available to us that run well in the local environment. Word processors, spreadsheets, sound, image and video editors, music and video library engines, educational software and a whole host more are all very well populated with traditional applications, so for the thinking user, there is no need to "go to the cloud" for classic compute tasks. Instead, the net can be used for communications, both as its heritage dictates and as the most sensible domain fit, while personal data and execution permissions remain secure in and at the local environment.
To help protect yourself, I suggest beginning by disabling flash, scripting and use only CSS/HTML in the web-facing interface. As a side benefit, surfing is much more pleasant without pop-overs, flash ads, and many other corporate infections of the network.
Neither Google or any other corporation has your best interests in mind. Start from that understanding, and the world will make considerably more sense.
I've fallen off your lawn, and I can't get up.
Yes.
I'm running a dual processor Xeon 2.4GHz with a Radeon HD3850, and it's very choppy and inconsistent. Once I click to blow it up, framerate drops to about 5.
isn't that the point here, that this dead-loss hack of different technologies would've taken us back to the days of "this website is best viewed with [insert favorite browser here]"
people are not going to buy that, whether devs or end users, so just forget about it.
And my E4500+HD5770 runs the video and the "blow up" completely smooth. So... I guess it's mainly a GPU thing?
If you use Windows 7, there's an extension to play H.264 videos on Firefox using the system codec.
Dilbert RSS feed
I'm running a dual-core 1.8GHz Pentium with whatever graphics card HP decided to slap in (the driver is identified as "Intel(R) Q965/Q963 Express Chipset Family") and it plays about as smoothly as I care to have any YouTube videos look.
In Second Life there are denial of service attacks on the GPU going on as we speak. People who gather at infohubs to voice chat are occasionally knocked offline by them. It can clear a room full of people in seconds. Basically, the attacker wears a spiked sculpty (a texture that turns into geometry) that is far more processing than the GPU can handle rendering. It looks like static on your screen essentially, you lag like hell, and then you crash hard. The only way to stop it is if you get lucky and smash the key combo for disabling Volumes or already had it disabled, they combo is CTRL ALT SHIFT 9. Volumes are prims (geometry primitives), which include sculpties and also regular geometry (cubes, spheres, torus, etc) and by disabling it hair, buildings, floors, walls, jewelry, shoes, etc all vanish. You're left looking at a pretty blank world with more or less naked avatars. The people who commit these attacks are usually either just trolling for the lulz, or they have a chip on their shoulder because they've had their asses handed to them in an argument over mic in that hub. Which is often the case. I'd say it probably happens at least 2 or 3 times a day, if not more, in the korea1 infohub for example. Also, it's been reported that it can also potentially damaging your graphics card. If you can't stop it with the key combo fast enough, you're best off killing the application with Task Manager as soon as you notice it happening.
No, the point is that if you're one of the outliers who still hasn't moved to a modern browser that supports basic HTML5 video...
Get a real browser.
It works in Firefox and Opera. I can't test it in Chrome.
I've already had a newer version of Firefox crash an older X11 display driver. Absolutely rock solid on Firefox 3.6 and down, and every other program I want to run. But the new GPU acceleration in Firefox? Could cause all of X11 to go away.
And Flash inside Firefox would pretty much guarantee a visit from the Coredump Gods. Fixed with a newer driver, but man is updating annoying.
Kinda sad that "web browsing" is the most intense job run on my work machine. I would have thought the massively parallel builds, or data simulation code, or something that actually pegs all the CPUs would be it. But no, it's the web.
Is it?
Yes. There are still tons of videos that still are only available in the old Sorenson video codec served up through flash.
I especially like this part:
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)
It elegantly scares ordinary people with sciency words and silently implies equality/correlation between "arbitrary (Turing Complete) programs sent for GPU execution via kernel-level drivers" and "arbitrary programs executed in the most protected part of the computer (Kernel Mode)".
By the way, aren't there moddable games out there that allow modders to use their own shaders?
I can't seem to remember, when was the last "a malicious shader in mod for game X exploits the vulnerability to raise privileges and install rootkit" incident, could anyone point me to one of those?
First, WebGL sends shader source code to the browser and the code is compiled and executed in OpenGL. This is no different from running any other OpenGL program on your machine. The remote attacker cannot make the GPU execute arbitrary hardware instructions, only whatever source he sends.
The shaders pretty much execute in a sandbox (shader on GPU can only access buffers bound textures, vertex buffers, constant buffers, render targets etc etc). The access outside these buffers is not possible because the hardware enforces it (there is no way to even address outside texture or render target). It is little more complicated with compute shaders which have little more flexible addressing but they still cannot access anything outside global buffer (or OpenCL address space). It is like segment based protection in CPUs.
Latest GPUs have actual page table and VM, so on top of security protection from "segment" based addressing, there is also VM/page table based protection which only allows particular GPU context to access pages that have been allocated and mapped into it's VM.
The only real problem is a possibility of DOS attack caused by the fact that GPUs are not preemptable. Therefore if you send some complicated geometry or you write a shader that takes a very long time to execute (multiple nested loops+many pixels/vertices or compute threads) the draw can execute for a very long time. On Vista and later this will cause TDR and kill the trouble process. It happens all the time if you develop games or GPU compute apps. The only way to disable the watchdog is with a registry setting. On XP the watchdogs are implemented in the kernel part of graphic driver (ATI VPU Recover, and whatever nVidia has).
This DOS is a little more problem in Linux since it doesn't have good watchdogs, the DOS should not crash X, but it will definitely lock the UI. Also, if you will bother to take look at the shader docs for AMD http://www.x.org/docs/AMD/r600isa.pdf you will see that the instruction set does not allow for truly infinite shaders, there are no arbitrary jumps, the loops cannot run forever (max loop count is 2^31), the flow control is only structured and easily verifiable. It is different for nVidia ISA which looks more like regular CPU and I think can do infinite loops.
On the upside Linux DRM drivers in kernel have pretty good command buffer parsers and validators, so it is hard for user-space driver to access memory that doesn't belong to it. On Vista and later the user-space driver doesn't even know GPU side addresses of its allocations and sends every render buffer with an allocation and patch list which is resolved and patched by VidMM and kernel mode driver, see D3DKMTRender function etc http://msdn.microsoft.com/en-us/library/ff547145%28v=vs.85%29.aspx
As with the previous article, this is much ado about nothing.
The GPU can only run "arbitrary code" in the loosest possible sense. What happens is that an OpenGL or WebGL application gives the shader source code to the driver, which then compiles it into the native GPU instructions. You *can* pre-compile your shaders in OpenGL ES 2.0, but even then it's just intermediary bytecode, and the bytecode is vendor-specific.
Furthermore, GLSL, the language used for OpenGL and WebGL shaders, is *very* domain-specific. It has no pointers, and no language support for accessing anything outside the GPU other than model geometry and texture data. *AND* it can only access the model geometry and texture data that the application have provided to it, and for GPUs that don't have any on-board VRAM it's up to the *driver* to determine where in shared system memory that the texture will be located.
And you can't get around using shaders on modern GPUs. Modern GPUs don't have a fixed function pipeline, it's not in the silicon at all. For apps that try to use the old OpenGL fixed function pipeline, the driver generates shaders that do what the fixed function pipeline *would* have done based on the current state. Drivers won't keep emulating the old fixed function pipeline forever, though.
Core 2 Duo here, 2.16GHz (mobile version, not desktop). CPU usage for the browser is at 86% playing the video, at 105% (i.e. one and a bit cores worth) when I explode it. No loss in framerate. Sounds like your browser is the problem...
I am TheRaven on Soylent News
Runs at about 4fps on my N900, even when blowing up the video, so something's seriously wrong with your computer.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Don't you remember how the hacking was done in Hackers?
What on earth could go wrong... *facepalm*
But I guess it still beats the shit of the disease that is Flash.
"When in doubt, use brute force." Ken Thompson