Jump to content



Photo

WebGL - A New Dimension for Browser Exploitation


  • Please log in to reply
No replies to this topic

#1 alexalex

alexalex

    Neowinian Senior

  • Joined: 25-February 11

Posted 11 May 2011 - 18:47

..Context recommends that users and corporate IT managers consider disabling WebGL in their web browsers.


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....

Denial of Service

The risk of denial of service is one of the most well known security issues facing WebGL, not least because it is even documented in the current standards documentation (see https://www.khronos..../specs/1.0/#4.4). 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 trivialise client denial of service attacks when the only affected component is the browser process (there are numerous ways of doing this already), however in this case the attack can completely prevent a user being able to access their computer, making it considerably more serious....

Cross-Domain Image Theft

...The WebGL API is built on top of the ‘Canvas’ element and so extends the concept of the flag to also encompass the use of cross-domain textures (see https://www.khronos..../specs/1.0/#4.2). This would be the end of it except for one slight issue. As already discussed with regards to denial or service it is possible to cause shading code and geometry drawing to take a non-trivial amount of time. One of the resources which a shader can directly access is the pixel data of textures, which once it reaches the shading code it no longer has any concept of origin. Therefore it is possible to develop a timing attack to extract pixel values even if we cannot read them directly. This can be done by changing how long a shader runs depending on the colour or brightness of a pixel and measuring the time the drawing process takes in JavaScript. This is a standard attack technique in the security field although it is most often used for breaking cryptographic systems. In relation to WebGL it has already been mentioned in a public mailing list that this could be an issue (see http://lists.whatwg....rch/030882.html)....

Conclusions

Based on this limited research Context does not believe WebGL is really ready for mass usage, therefore Context recommends that users and corporate IT managers consider disabling WebGL in their web browsers.

While there is certainly a demand for high-performance 3D content to be made available over the web, the way in which WebGL has been specified insufficiently takes into account the infrastructure required to support it securely. This is evident from the development of ways to mitigate the underlying security issues by introducing validation layers and driver black-lists; however this still pushes much of the responsibility of securing WebGL on the hardware manufacturers. Perhaps the best approach would be to design a specification for 3D graphics from the ground up with these issues in mind.

http://www.contextis...ces/blog/webgl/