Google deserves much credit for the wealth of security information (download PDF) posted on the Internet and on its Google Chrome blog and for making Chrome’s source code available for anyone to examine.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 Inc.’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.
(Tomorrow: “How secure is Mozilla Firefox?” For more on browser security and protection against Web-borne threats, see Security Adviser and Test Center: Browser security tools versus the evil Web.”)
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. This screen image shows the various browser processes and their security settings, as enumerated by Process Explorer on Windows Vista. 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.
Interesting innovations
A slightly questionable choice is Google’s decision to allow Chrome to be installed without requiring administrator-level access. This can make Chrome installs difficult to manage in an enterprise environment, but Microsoft is encouraging this sort of behavior in all vendors (to prevent Windows system modifications). Chrome is just one of the first major apps to follow Microsoft’s advice.
Chrome also installs the Googleupdate.exe application. It’s scheduled to run automatically in Windows Vista Task Scheduler, which frequently dials home (although only when the user is logged on and the computer is idle), checks for browser (and other Google application) updates and silently installs them. This is a great way to keep the browser up to date — patches are currently applied more frequently than once a week — but it riles many security administrators because there is no notification of the outward-bound search, no notification of pending patches and no approval requested for patches to be applied. In addition, this behavior can’t be easily changed.
Another interesting concept is Chrome’s virtual JavaScript machine, called V8. Google’s Chromium team built its own virtual environment for all JavaScript execution. V8 even converts JavaScript code into native machine language (to speed up Web-page loading) and has its own memory garbage-collection processes, source-code inspector and debugger. V8 significantly limits what can be accomplished by JavaScript against the user’s system, including preventing the normal JavaScript pop-ups. In testing, Chrome did pretty well against pop-up ads but suffered from user-interface problems and slowness on some of the JavaScript modal tests.
Chrome has many standard security features, including a browser-session privacy mode called Incognito; antiphishing capability called Google Chrome’s Safe Browsing; one-button setting resets; forced file saves before launching; moniker handling, which helps thwart attempts to fool the browser into launching helper applications that can be exploited; and MIME content-type sniffing, which helps thwart attempts to fool the browser into downloading malicious content. Chrome actually has many more security features that I could go on about; so far, so good.
Questionable controls
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 can’t be breached, so despite all the cleverness that went into V8, I can’t 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 — it seems that the only recommendation Google will be able to offer will be 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. For example, all cookie types (both first- and third-party) are allowed by default. This isn’t surprising for a company that makes its living from ads. But even the third-party-cookie restricted mode allows the reading of any third-party cookie, which is almost as bad as allowing modifications. In another example of a poor default, HTTP data is allowed to commingle with HTTPS data in the same view, without warning to the user.
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.
Google has also washed its hands of responsibility for the security of add-ons. Reviewers are very mixed on this approach. While it is true that browser vendors should not be ultimately held responsible for others’ add-ons and applications, Chrome offers no add-on management. You can’t easily determine which add-ons will render particular content, nor can you easily disable them.
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 plain text with a few clicks of the mouse. This is convenient for the user — and for anyone else who wants to learn all of the user’s passwords and finds the computer left unattended for a few seconds. Internet Explorer doesn’t allow this at all, and Firefox and Opera at least have the ability to assign another password to protect the saved passwords. On the Password Manager Evaluator testing Web site, Chrome scored the worst among all of the browsers I’ve tested, including Firefox, Internet Explorer, Opera and Safari, passing only four of 21 tests.
Bugaboos
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.
On a good note, Chrome passed all of the browser security tests I threw at it and prevented the automatic installation of any malware. These tests included dozens of predefined tests made in the lab, several browser-security tests on the Web, including scanit and Jason’s Toolbox. I sniffed traffic looking for information leaks, tested the browser’s handling of cross-site scripting, tested privacy features, confirmed digital certificate handling and surfed to more than 100 malicious Web sites. With less than 2% market share, Chrome isn’t yet the popular target of hackers. That gives its users additional insulation compared with its competitors.
One key feature simply doesn’t work as promised. Google repeatedly makes the claim that Chrome’s rendering-process isolation prevents one browser session from bringing down another or affecting the whole browser. Yet, vulnerability after vulnerability has proven that Chrome’s process separation isn’t nearly as perfect as it sounds on paper. Malicious Web pages of all kinds have caused denial-of-service problems, lockups and complete system failure. I and every other Chrome user I know have experienced complete browser lockups while browsing ordinary, legitimate Web pages.
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 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. This may be Google’s first version of its first browser, but it has more experience with browsers and malicious content than any of its competitors. Why introduce yet another new Web browser and not blow away the competition?
Chrome’s excellent security model and newness give it a chance to quickly improve in areas where other vendors must tread more slowly because of backward-compatibility issues. The real challenge is that the bigger flaws are human- and process-oriented, and they can’t be solved with fast patching. They are systematic and will require a serious paradigm shift within Google to achieve.
Source:
computerworld
Searching from the address bar 
