Google Chrome – which covers about 60% of browser population in Internet – has respectable security designs and appropriate user controls for balanced user privacy and security. Of all, most notable is a sandbox feature, which is based on Google’s second design principle: “non-malicious code does not try to access resources it cannot obtain” (Chromium). Essentially, as sandbox itself shouldn’t require superuser privilege, consequently, there is no need for its’ contained processes to inherit the prerogative of administrator. At the time of writing, Google Chrome version indicates: version 37.0.2062.102m. This update covers about 50 security flaws – found in Google bug bounty program and independent security experts/researchers – ranging from out-of-sandbox (“escaped,” more specifically) remote code executions to minor bugs. These three are my favorites and their applicable descriptions in our life respectively:
1. [CVE-2014-3176, CVE-2014-3177]
The most intricate idea has a very basic origin: this vulnerability, similarly, has a pervasive network attack range as well as low complexity requirement. This vulnerability deals with Chrome’s improper handling of IPCs, sync API, and V8. IPC, or inter-process communication – deals with handling with multiple processes. This benefits to processes which depends on other processes. Sync API – used also in DropBox - syncs changes made in remote environment. That’s how it “knows” that you’ve updated a particular Word documents and syncs it with the host. Lastly, the V8 is Google’s unique JavaScript engine which strives to minimize the access speed of resources and make garbage collection efficient. With the improper handling of the three, the effect on the customers were pretty devastating – from disclosing unauthorized information to unauthorized modification. The possibilities for damage are endless and extremely dangerous. I mean, exactly when do we know we are truly safe from outside? How can we take additional measures to restrict and minimize the threats posed by the unknown?
2. [CVE-2014-3170]
This vulnerability marks “extension permission dialog spoofing.” When you install an extension, remember how you get those prompts such as ‘access your data on www.google.com’ or ‘access your tabs and browsing activity?’ Before Chrome 37.x.x.x, an extension permissions were spoofed to show minimal, different, or none. While browsing, for example, a seemingly innocuous extension could be extracting browsing habit data.
3. [CVE-2014-3173]
This is uninitialized memory read in WebGL. WebGL is a JS-based rendering of 3D and 2D graphics in a browser. Using Java, for example, to initialize an object, you would specify two things: object type and the “container.” Now, why is uninitialized memory read illegal to a program? Well, that’s because several things can happen: memory corruption, really hard tracing of the corruption, unwanted collection by garbage collector, etc. A similar case study can be seen with Heartbleed and OpenSSL. Essentially, improper input validation would cause extra spaces of memories to be read/collected and reversed to reveal sensitive information loaded onto a memory.
As with number of patches seen in Google Chrome, each seems to indicate that there are numerous problems which exists in any computer software: there cannot be 100% immunity to newer technologies and exploitation techniques. Perhaps, that is the technologies' greatest gift and a curse.
(*) Chromium – The Chromium Projects (Sandbox)
No comments:
Post a Comment