New graphics engine imperils users of Firefox and Chrome The US Computer Emergency Readiness Team is advising users of the Mozilla Firefox and Google Chrome browsers to disable a recently added graphics engine that can be exploited to steal data or crash end user computers. The web standard known as WebGL opens the browsers to serious attacks, including the theft of images or denial- …
A random company appears and says there is a non-specific but nevertheless major security flaw in a very marketable feature supported by all the major players except Microsoft?
The needle on my FUD gauge is buried in the red, the glass has cracked and there is an ominous rumbling coming from the bullshit storage tanks....
Step away from the tinfoil hat. If CERT are going along with the advice, it's a good idea to at least consider it, rather than indulging in kneejerkery.
Given that you're missing nothing other than some horrid browser demos (which run like crap on a quad core machine wtih a Geforce 580), it seems like a small price to pay. It certainly won't give anyone much of an advantage right now.
But only a bit :p
'Context Information Security' would be the 'random' company.
Reading Context's report it appears that their grievance with WebGL is that it offers direct access to the GPU, which may have buggy or insecure drivers. So it is not WebGL that is the problem, it is just that it opens the possibility of underlying problems being exploited.
CERT's agreement or not, there is something about an 'independent research consultancy' making sweeping recommendations based on 'limited research' and arguably blaming the wrong link in the chain that screams 'FUD'.
This has nothing to do with browser vulnerabilities. AFAICT the browsers are just passing OpenGL instructions to the graphics card.
This has _everything_ to do with graphics driver vulnerabilities. I'm sure anyone who's made graphically-intensive software (eg. games), or just tried to run them on their computer, can tell you that graphics card drivers can be some of the quirkiest, buggiest, unstable blobs of code on the machine. And these are Windows systems we're talking about!
That's not to say the browser makers should ignore this issue completely, but sometimes you just need to steam ahead, in order to force the moose to get off the track.
Running them over will teach the others.
Seriously, you are suggesting that the most beneficial possible thing for users will be to convert a local privilege escalation vulnerability into a remote execution vulnerability?
Fantastic idea. Not.
...of finding "disable.webgl" in about:config, it might be nice if they actually included (in either advisory) instructions - well done, El Reg, on noting their absence. All very well telling everyone the sky's falling; telling them where to find the umbrella would also be good....
indicates that only a "preview build" using WebGL has been released for Opera, not the standard edition browser.
http://groups.google.com/groups/search?qt_s=1&q=WebGL+group%3Aopera.*
only finds one mention of WebGL in Opera's newsgroups, but
http://my.opera.com/community/forums/search.dml?term=WebGL&id=
has more. But that still seems to be the position: WebGL planned for Opera 11.50 or thereabouts, currently under development; but, once they hear about this, perhaps not.
This GL_ARB_robustness extension just sounds like a hack, a bit like the alleged "safe for scripting" bit that MS used to allow ActiveX controls to set if they wanted to run in a browser. What does it even mean on the backend? Are NVidia / AMD really going to sanity test every single value coming through their OpenGL implementations? I'm not sure how you could ever be certain that a card is safe from hacks given the multitude of ways they could be abused.
<p>
That said, the same is probably true of regular 2D canvas operations too. If Firefox or any other browser ultimately uses hardware acceleration its quite possible that a bug in the impl could make the entire machine vulnerable in some way.
How exactly is WebGL different from regular 2D operations?
Both provide access to video hardware, and both could be used to exploit bugs in the video drivers. The fact that one is for drawing 2D, and the other for drawing 3D is largely irrelevant. If you want to be "safe" against such attacks, disable all hardware acceleration and have your browser render into a dumb framebuffer (note, this will be very slow).
Generally, with 2d you are, in effect, manipulating a framebuffer. normally the OS would provide you some primitives (which it can sanity check) or a framebuffer ("Canvas" if you prefer) and not actually provide you with direct access to the hardware. (at least insofar as what is provided to a web browser is concerned)
With 3D, OTOH performance becomes a much larger issue. We generally offload that to a GPU, shaders get written to run on GPUs. Because we pass the code to the GPU, to run directly on on the concern that it could be used as an attack vector to a system is solid one. For example, something like a shader which gets random chunks of memory looking for private keys. The OS is not designed (can it even be?) to protect against a processor on a compromised peripheral as an attack vector. It basicly allows anyone to do a "drive-by hacking" using, essentially, the same attack vector as the usb-dma vector.
http://www.google.com/search?q=USB+DMA+Attack
What bothers me about this article is not the vulnerabilities themselves. Yes, graphics drivers are buggy, any most likely exploitable through GLES and GLSL if you're not careful. This is bad.
What bothers me is that it is being painted as an end-of-the-line, unfixable problem for WebGL. It's not. Browsers could add sanity checking to values passing through the WebGL layer. GLSL shaders could be sanitized. It'll hurt performance a bit, but what are you going to do? Hell, Google Chrome on Windows is already passing the OpenGL commands through a translator (ANGLE) to translate them to DirectX (and therefore is translating GLSL to HLSL) to bypass the dodgy OpenGL situation on Windows, so I see little reason why sanitization cannot be added to this as well. Similar should be possible for any browser, though Google may have a head start due to ANGLE.
I'm not saying this will be easy, but I really don't see why it's painted as being so very impossible. Hell, Google wrote a sandboxing architecture to allow x86 code to run safely from the web. This should be doable.
If we're saying that video drivers and GPU hardware are buggy and can allow arbitrary execution of code on a PC (are we?), then even "sane" input values may lead to erroneous behaviour. To race conditions. To data corruption and bad code execution, in ways where we don't yet know that there's a problem.
Having said that, non-sane inputs are more likely to lead to fun misbehaviour of your PC.
Without any sort of statement as to which manufacturers, GPUs, and graphics interfaces (PCI-E or AGP) are vulnerable, this statement by CERT becomes a scare tactic. There is also nothing to tell us when and where WebGL is used by which types of rendering, other than some sort of 3-D.
If I do not view any 3-D objects in my Firefox brower, is my system still vulnerable?
Too damned many unanswered questions here. CERT, go back to the drawing board and give us a statement with some meat... Ben Myers
CERT issues a warning against FF but it must be FUD they must be a MS shill. CERT turns around and says that active X on SCADA systems is a danger and not a peep. So it's not that you folks don't believe CERT you just will only believe things when it's against MS but if it's against OSS it's fud 100% of the time .
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
