I was reading a recent article on Infoworld.com about a review of the Google's Chrome Browser. The article from January 26, 2009 is entitled Test Center: How secure is Google Chrome? and written by Roger A. Grimes. Grimes provides some good analysis and commentary regarding the latest browser, but what strikes me as odd and begs the question "What Determines an 'Excellent' Security Model?"
Grimes makes the following comment:
"The security model Chrome follows is excellent. Chrome separates the main browser program, called the browser kernel, from the rendering processes, which are based upon the open source WebKit engine, also used by Apple's Safari. The browser kernel starts with all privileges removed, the null SID (a security identifier in Windows Vista that denotes the user as untrusted), and multiple 'restrict' and 'deny' SIDs enabled. On Windows Vista, Chrome runs as a medium-integrity process.
Every Web site is given its own separate rendering process, memory space, global data structures, access token, tab, URL bar, desktop, and so forth. Currently, Chrome will open as many as 20 separate processes, one for each Web site, and start sharing processes between Web sites after that. Rendering processes are highly restricted as to what they can and can't do. On Windows Vista, Chrome's rendering processes run with low integrity, much like Internet Explorer in Protected Mode. But Chrome actually uses Vista's mandatory integrity controls more securely than Microsoft does. For one, Chrome attempts to prevent low-integrity browser processes from reading high-integrity resources, which is not normally prevented. (By default, Vista prevents lower to higher modifications, but not reads.)
Both the browser kernel and rendering processes run with DEP (Data Execution Prevention) and ASLR (Address Space Layout Representation) enabled, and with virtualization disabled. Any supplementary browser add-ons are run in a separate, medium-integrity (or higher-integrity) process. Chrome even has its own Task Manager and internal page to show memory and CPU statistics. With respect to the base security model, Chrome is leading the pack. It's beautiful."
This description makes a good case for using Chrome as an improved browser, but as you read further within the article, some statements begin to change that perception. Comments and analysis such as:
"A slightly questionable choice is Google's decision to allow Chrome to be installed without requiring Administrator-level access...
But then reality hits hard. One of the most glaring lapses is the inability to disable JavaScript. Because JavaScript is involved with most malicious Web attacks, all of Google's competitors allow its use to be disabled globally, or per site or per zone (albeit Firefox requires a third-party add-on, NoScript, to be site-specific). The world has yet to create a virtual machine that was not able to be breached, so despite all the cleverness that went into V8, I cannot understand how Google committed such an oversight, even if the company is trying to promote JavaScript-enriched applications and sites. If a large JavaScript exploit happens against Chrome -- or rather, when it happens -- the only recommendation Google will be able to offer, it seems, is to stop using it...
Most user-selectable security settings are under an option tab called Under the Hood. It's when you first go here that you realize how little Chrome offers in the way of fine-grained security settings. The options are very sparse and often lack a secure default...
Another critical security feature that's missing is the ability to place different Web sites into separate security zones or domains. Most browsers provide at least two zones (Internet Explorer has five) or the binary ability to whitelist or blacklist sites. Chrome is also glaringly absent of enterprise management features. SSL/TLS (Secure Sockets Layer/Transport Layer Security) server revocation checking is enabled by default, but Chrome does not support the more efficient OCSP (Online Certificate Status Protocol) revocation-checking protocol, though all of its competitors do...
Many users are perturbed by the treatment of their own saved passwords. Chrome allows the current user to reveal the saved log-on names and passwords in plaintext with a few clicks of the mouse...
Chrome has a very limited feature set and relatively moderate complexity. This might help it avoid some security issues in the long run, but so far it hasn't. Chrome has had 10 exploits in the five months it has been released (you can search on keyword Chrome at milw0rm.com to see the individual exploits). They have been patched. Most were simple denial-of-service exploits, but at least one allowed complete system compromise and another allowed malicious redirection...
Far more indicative of systematic problems is that the initial vulnerabilities found in Chrome were very simple, well-known exploits. Initially, Google shipped its beta with a known vulnerable version of the WebKit engine, for which a patch had been issued months before. I realize it was only beta code, but how embarrassing. The buffer overflow attacks that were soon discovered were often simple string overflows, a vulnerability that any normal security code review or fuzzing tool should have found. Most of the other vulnerabilities were flaws that had been widely reported in other browsers and should not have been present in Google's first try. Google should have known better."
This type of insight and issues make you wonder if you can classify a security model as excellent, if the key and default mechanisms of the model are not implemented or problematic. This is not to say that Google may not be on the right track, but it definitely has some maturing to take place. That being stated, can Google's Chrome browser be given an excellent in the area of security model and security in general with such deficiencies still clearly present within the product. I think Grimes sums it up very easily, and maybe should have stated this in the introduction as well, in the following:
"This is the security paradox of Chrome. It begins with a beautiful idea and an excellent security model but then compromises the vision with questionable decisions, a dearth of granular security controls, and the obvious failure to perform a serious code review...Why introduce yet another new Web browser and not blow away the competition?"
I am interested to get comments and see what others would have to say regarding the definition of an Excellent Security Model. Should the model also be effectively implemented?
I read the other articles, as well as this one. I agree that applying the term "excellent" to the Chrome security model is questionable, at best. Separation of the browser kernel from the rendering engine, and limiting privileges, is a good thing in theory. I submit that it has some practice to go through before I'd call it excellent. The same model was applied to NT4 and later Windows platforms, separating the OS kernel from the application space, with varying success. As far as any level of excellence that concept may have ... well, some problems were solved only to make way for new ones.
The articles do provide interesting examinations of the major browsers and I'm looking forward to the last installment. I'm not convinced that one is any more secure than another, though. A stupid mis-click in Chrome is probably just as devastating as a stupid mis-click in Firefox or IE. The fundamental flaw of any browser is the assumption that the user is conscious of what he or she is doing and paying attention to what is on the screen.
Posted by: Guy | 28 January 2009 at 05:25 PM
Guy,
I agree with you. I think that the overall set of reviews on all three browsers is very good, but the statement of "Excellent Security" model lends itself to misinterpretation.
Posted by: Lester Nichols | 30 January 2009 at 01:13 PM