In the post ... it mentioned..
We believe this initiative will help our users in the following ways:
* When users download Chrome, they will also receive the latest version of Adobe Flash Player. There will be no need to install Flash Player separately.
* Users will automatically receive updates related to Flash Player using Google Chrome’s auto-update mechanism. This eliminates the need to manually download separate updates and reduces the security risk of using outdated versions.
* With Adobe's help, we plan to further protect users by extending Chrome's “sandbox” to web pages with Flash content.
The 1st two points are trivial, but the 3rd? This is the reason why i'm writing this post.
The 3rd generated my interest in knowing more about the sandbox model of Chrome and thus leading me to read their "technical report".
In the following paragraph, i will briefly explain the architecture of Chromium based on reading their "technical report". (Note: I didn't read any source code of the beautiful Chromium project and their "report" was published quite a while ago. Thus, some info. below may be inaccurate or outdated but fairly enough for u to get understand with their sandbox model.)
---
Here we go.
---
In the chromium architecture, the web browser is separated into two core components: the rendering engine and the browser kernel.
Here is the task assignments mentioned in the report.
Rendering Engine: HTML parsing, CSS parsing, Image decoding, Javascript interpreter, Regular expressions, Layout, Document object model, Rendering, SVG, XML parsing, XSLT
Browser Kernel: Cookie database, History database, Password database, Window management, Location bar, Safe browsing blacklist, Network stack, SSL/TLS, Data cache, Download manager, Clipboard
And, both of the components can carry URL parsing and Unicode parsing.
From their design philosophy, the rendering engine is always subjected to a bunch of known / unknown vulnerabilities. Thus, they decided to grant limited privileges to the rendering engine while letting the browser kernel to have the user's privileges.
These two components are communicating with IPC (Inter-Process communication) from a "big" picture in the report and the browser kernel provides API for the rendering engine to use its services.
Before i continue, here is a remark. Their report mentioned:
Chromium's security architecture mitigates approximately 70% of critical browser vulnerabilities that let an attacker execute arbitrary code.
Where is the rest 30%? You will, perhaps, know later.
Whenever a user create a new tab in Chrome, the browser kernel fork() a new rendering engine with a sandbox. What is the sandbox? On windows, it's the Windows Security Manager. The rendering engine runs with a "restricted security token", that is used by the security manager, on a Windows Job Object. Whenever some action is performed by the rendering engine, the manager will check for privileges.
It sounds work ... but some known limitations in this M$ windows sandbox.
[1] FAT32 - FAT32 does not support the access control list and thus user's USB thumb with FAT32 format may be read or write by a compromised rendering engine.
[2] Misconfigured objects - Some application create objects with NULL DACLs. This will let security manager ignore the security token owned by rendering engine. (But NTFS mitigated that)
[3] TCP/TP - Theoretically, rendering engine can create any socket as it wishes... (But Win API require a "handle", which the rendering engine will not hv, to open a socket ... a bug in Win API?? or a feature??)
As a result of using the sandbox, even a rendering engine is compromised by buffer overflow of HTML parser, integer overflow of regex, or what-so-ever related to attack against rendering engine... [a] the attack can only use the restricted sandbox to do the bad ... [b] or invoke the IPC with Chrome's browser kernel ... [c] or if m$ security manager hv bug, sandbox broke too
You may noticed that [a] is assumed to be secured and [c] has nothing to do at all since m$ is "closed". The only problem left is [b] ... attacker insert code to invoke browser kernel to do bad.
Now, let's see how's kernel work.
Browser kernel API handles a few things. User interaction, persistent storage, and networking.
User interaction includes - rendering and user input.
Rendering is handled by the rendering engine. Unparsed HTML is sent to the engine and a bitmap is returned to the browser kernel. The kernel uses the trick like "double-buffering" for the bitmap and presents it onto screen.
User input either occurs on Chrome's body (they call it browser chrome) like location bar or within the web page. For former case, kernel will handle it. For latter case, kernel asks rendering engine to render the input as bitmap again. Even rendering engine is compromised, it cannot receives keyboard signals.
Persistent storage includes - upload and download.
Upload is handled by kernel. When user selects certain file, kernel will ask to render the selection path and keeps records of which file the user granted to the web (engine) to access. Even compromised, the engine cannot touch those files which are not granted yet.
Download is also handled by kernel. Kernel API provides method to invoke a download action which the kernel will blacklist some filename like desktop.ini (M$ vulnerable feature). Even a rendering engine is compromised, the engine cannot ask the kernel to download some file to anywhere on user's disk.
Networking includes URL requests.
Rendering engine itself is allowed to fire requests for protocol like http, https, ftp, etc. But not the file://
File opening is handled by browser kernel when user type in file:// in the location bar. The file is rendered in a dedicated rendering engine.
After the long boring things... you will noticed that ... Chrome actually deals with 3 security threats. [1] Persistent Malware, [2] Transient Keylogger, and [3] File Theft. Other threat like phishing, origin isolation, firewall circumvention, and website vulnerabilities are not in scope of Chromium written in the "technical report".
Last but not least ... why bundle Flash (a "the most widely used web browser" plugin?) There is a small paragraph in the report talks about plug-in. From historical reason, plug-in is a separate host process which execute outside the browser.
In order to maintain compatibility with existing web sites, browser plug-ins cannot be hosted inside the rendering engine because plug-in vendors expect there to be at most one instance of a plugin for the entire web browser. If plug-ins were hosted inside the browser kernel, a plug-in crash would be sufficient to crash the entire browser... each plug-in runs outside of the sandbox and with the user's privileges... For example, the Flash Player plug-in can access the user's microphone and webcam, as well as write to the user's file system (to update itself and store Flash cookies).
...
Chromium also contains an option to run existing plug-ins inside the sandbox. To do so, run the browser with the --safe-plugins command line option. This setting is experimental and might cause instability or unexpected behavior.
So... you know why "With Adobe's help, we plan to further protect users by extending Chrome's “sandbox” to web pages with Flash content." (Flash player like m$ is "closed")
The chromium team phoned adobe and says... let's work together to secure Flash and silent those who against Flash coz of security concern in unknown implementation flaws. H.264 video codec will keep on our Utube. (this paragraph is some "bs" that comes to my mind)
