Is WebGL Secure?

Innovative Web technologies from its introduction ,is always been exposed to exploits, so is in the case of latest web trend WebGL [to know more on basics of  WebGl,visit our earlier post].Now most tech websites are exposing news regarding the vulnerability on the new 3D graphics technology WebGL that allows web pages to draw fast 3D graphics in a similar manner to computer games.Although this exciting technology has the capability to deliver a much richer experience to web users, recent research shows it can be used steal user data through web browsers.

It was a nice experience for us and might be for our readers that don’t jump into conclusion on to the latest web technologies before knowing what it lacks.In And so is now watching the research done by Contextis , many developers is heading a hawk eye towards WebGL.

What are the Security Flaws with WebGL?

Going deeper to this exploitation scenario , what a WebGL code in a webpage does is that the web browsers (currently Chrome and Firefox) have had to expose low-level parts[system specific] of their operating systems which previously[before WebGL] could not be directly accessed by potentially malicious web pages, thus creating a number of potential security vulnerabilities.

Mainly 2 sorts of threats are exposed with WebGL.

  1. Information disclosure/Cross Domain Image theft :Capture screenshots of any window on their system,these screenshots could be of other web pages, the user’s desktop and other applications that run on their system.
  2. DoS[Denial of Service]attack :flooding/overloading your graphics card and leading to system crash

How this threat are Applied
It’s a bit of programming & system level scenario.However let’s try to explain a short of the research conducted by Contextis on this exploit.Basically most modern PC style architectures implement 3D graphics pipeline/view as a Kernel Mode [consisting of Graphics card & Drivers] and a User Mode consisting OpenGl interface /API .In between these two comes the scheduling Mode.Scheduling could be implemented in a number of different locations, for example in the kernel driver itself, by the OS or entirely in user mode. Its responsibility is to share access to the GPU between individual programs running on the same machine.

There is an individual programmable units usually referred to as shaders, which can be individually programmed by the user-mode processes.These shaders are contained in almost all modern 3D hardware/Graphics card.These shader codes native formats are always specific to hardware vendors[like NVIDIA ].Traditional browser content would not normally have direct access to the hardware in any form[i.e to the Kernel Level].but this is not in case of Latest WebGL.Shader code, in an WebGL environment, has direct access to the graphics hardware. Shader code, while not written in the native language of the GPU, are compiled, uploaded then executed on the graphics hardware.

Basically because of the almost direct access the WebGL API has to the graphics hardware it is possible to create shader programs or a set of complex 3D geometry which can cause the hardware to spend a significant proportion of its time rendering. It is easy to create a client denial of service attacks[DoS] in this case the attack can completely prevent a user being able to access their computer, making it considerably more serious.These leads to system crash or Blue Screen of Death.Windows 7 and Vista seem to fair slightly better in this regard, if the GPU locks up for around 2 seconds the OS will force it to be reset. This stops all applications from using any 3D graphics during this period of reset. However these OSes also have a maximum limit to how many times this can happen in a short time window before the kernel will force a bug check .

After reviewing these exploits research conducted by contextis Firefox has now removed support for cross-domain images (https://hacks.mozilla.org/2011/06/cross-domain-webgl-textures-disabled-in-firefox-5); while Khronos[WebGL vendor] is updating the WebGL specification to include protection from DoS (using a new OpenGL extension GL_ARB_robustness) and Cross-Origin Resource Shading (CORS) attacks .

Debates on WebGL & Microsoft SilverLight  related Technologies

Now these sort of exploitation techniques on WebGl has created a discussion/debate  regarding major Developers of Microsoft & Chrome developers.Based on Contextis research Microsoft complained that WebGL is too reliant on third parties (ie, GPU vendors) to secure the Web experience.But latest news is that not only WebGL Silverlight 5 has the exact same vulnerability. However Microsoft says it has fixed the vulnerability and the fix will appear in the next beta release.Microsoft’s alternatives to WebGL are Silverlight and its hardware accelerated implementation of HTML5 (which it calls “native HTML5”) standards in Internet Explorer 9 and 10. Also, WebGL is based on OpenGL, which competes with Microsoft’s DirectX technology.

What Chrome Developer Gregg Tavares says[according to readwriteweb.com] “We studied this issue in-depth at Google and we’ve proven there is no way you can limit the features of access to the GPU enough to prevent this and still have useful access to the GPU. You can cause this with or without shaders. Fortunately there are solutions. The simplest solution is to time how long the GPU is taking to execute each task. If it’s taking too long reset the GPU and kill the page that issued the command. Microsoft Windows is one of the only OSes that currently provides this solution. They should be proud of this. They can basically claim the best place to run WebGL is on Windows. The Khronos group is working to bring similar functionality to other OSes as fast as possible and it may already be available in some drivers.”

Although the debate continues among developers ,many experts suggest that it’s almost  certain  that WebGL is essential for cross-platform, cutting-edge, next-gen web applications that will blur the line between native and web applications.However the flaws & exploits might be sooner rectified as WebGL is still considered  to be in Progress/Prototypes.

Do any one wants to know more on these WebGL exploits. Download PDF from the entire research done by Contextis.

Top this week Tech Updates

Advertisements

About Technology Timely

Aimed on updated tech news

Posted on June 23, 2011, in Firefox, Security, Technews. Bookmark the permalink. 2 Comments.

  1. There is not much danger with WebGl as expected .When told that it “gives web pages access to your graphics hardware”, some people worry that WebGL could be a serious security threat. It’s not as dangerous as it might sound, though!With current versions of WebGL, a hacker could potentially write a WebGL page that made your graphics card stop responding to other applications. Under Microsoft Windows Vista and Windows 7, this would be annoying but not disasterous — the operating system would notice that something was wrong and reset the graphics card. But under Apple OS X on a Macintosh, the hacker could potentially freeze the screen of your computer. On Linux it depends on what GPU you have and which drivers, Intel’s drivers are supposed to detect GPU lockups and reset the card (if your kernel is new enough to have this code anyway) for ATI the free drivers do lockup detection for some (older) GPUs, nouveau (free NVIDIA driver) doesn’t currently do hang detection. Basically the Linux situation is, at the moment maybe it’ll reset your GPU, but in the future it’ll get better (as usual for anything in Linux that sucks).

    Chrome browsers had a technique of handling WebGL safety.like everything in Chrome, we run the webpage in its own process. Even if the webpage could somehow execute native code it can’t access files. It can’t access the network. It can’t access the keyboard or the mouse. In the WebGL case it can’t access the GPU. All GPU access in Chrome happens in a separate process called the GPU process. We get 2 big benefits from this design.The first is that we can parallelize WebGL calls. Once your webpage has issued a command to draw it’s free to go do something else while a completely separate process goes off and actually sets up the GPU to do the drawing. For well written WebGL programs, all else being equal, this should make Chrome faster than single process architectures.
    The other is that the GPU process validates EVERYTHING!!!! before calling the GPU drivers.

    It validates all parameters so a webpage can not pass unknown parameters to the GPU.
    It validates the size of all buffers created and all access to them. The webpage can not exploit buffer overruns in a driver. This is part of the WebGL spec.
    It validates all indices against the size of all buffers that will be accessed during a draw call. This means a webpage can NOT submit indices that would access data outside a valid range. This too is part of the spec.
    It validates that all writing to textures is within bounds. This means a webpage can not submit texture data outside the bounds of a texture.
    It validates all buffers, textures and renderbuffers are cleared on creation. This means a webpage can not access data left over from other apps or pages. This is part of the WebGL spec. That Firefox had a bug in this area which has already been fixed. It was a bug in Firefox , not a bug in WebGL.
    It validates that every GPU object referenced by the WebGL page was created by that page. If it’s not the call is not passed through to the driver.
    It validates that the shaders submitted to the GPU use only the minimal features allowed by the spec. That means no dynamic indexing of sampler arrays. It means no infinite loops. There’s actually a huge list of features that native apps would have access do that are disallowed by this validation.
    The sad thing is, this is a chance for Microsoft to shine. They are currently the best OS for WebGL. They are clearly pushing Silverlight 5

  1. Pingback: Graphics Cards Face Internet-Borne Threats

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: