eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Everyone’s talking about Chrome, Google’s new Web browser that endeavors to be more than a web browser. It’s an exciting program in many ways, but none more so than in what they are attempting to do with browser security.
I won’t go into everything security-related in the program. For instance, the Incognito mode and blacklists are useful stuff but not exactly unique or innovative. It’s the architecture that has me intrigued.
If you want to learn about security in Chrome you can read the cartoon version or you can read the paper that the Chrome team wrote with people from UC Berkeley, Stanford and the University of Washington: The Security Architecture of Chromium. Chromium appears to be an application framework on which Google built Chrome.
Google has attempted to make Chrome more of a legit environment for applications than other browsers by giving the browser architecture some of the same protections that applications have on modern operating systems. Essentially, they run different pages in the browser, i.e., different tabs, as separate processes, and run them in a sandbox. Each of these processes is limited in ways that should limit the damage of any malicious programs that execute. More specifically, the browser is divided into two components: a privileged browser kernel and a rendering engine which runs in a sandbox. This is the component which performs many of the tasks, such as file parsing and Javascript execution, which are prone to vulnerabilities.
The notion of the browser as an application platform is not a new one. Apple tried to claim for quite a while that Safari was the application development platform for the iPhone, but that didn’t satisfy many people. And security in general, let alone in Safari, has not been one of Apple’s strong suits. Google doesn’t have a real track record here, but they seem to have the right ideas.
I’m not the only one excited by Google’s nerve in this regard: Microsoft’s Robert Hensing notes, and I think fairly, that much of Google’s approach mirrors Microsoft’s attempts with IE Protected Mode and related features, but that Google goes further by isolating tabs as processes. Read Robert’s second blog on Chrome for a short version of how Google is implementing their sandbox in Windows. There are more details here in the Chrome Design Documentation.
If you go through the docs, though, one interesting fact is that they are using Windows-specific security features to implement the sandbox (CreateRestrictedToken, Job objects), features which mostly don’t have counterparts in Linux, the Mac and other platforms on which they might wish to implement Chrome. The only version available now (that I can see) is the Windows version. How are they going to implement the sandbox on other platforms?
I’m a big fan of such architectural improvements that attempt to limit the reach of any successful attack or reduce the attack surface, but it’s not yet clear that Google has done what they set out to do. Even just on Tuesday, the first day that Chrome was released to the public, the security research community dropped what they were doing and produced what could be real problems. Look for more of this stuff as people have more time to work on it.
A revelation on Full-Disclosure of a crash bug in the browser at first brought forth scorn from me; a crash in a beta browser? Stop the presses! But as others pointed out, just about everything from Google is forever in beta, so they deserve more scrutiny than most companies would get for a beta product. On the other hand, someone suggested that because of the Chromium architecture just the one tab was crashed, not the whole browser. I’m not so sure.
I tried the proof of concept for this bug. The browser successfully restarted (“Whoa! Google Chrome has crashed. Restart now?”), but it seems to me as if each of the pages is being reloaded, which means the whole browser crashed. Perhaps Google will comment on the report.
Another more interesting report was a ZDNet report that Chrome is vulnerable to same “Carpet Bombing” bug as Apple’s Safari (credit for the research to the prolific Aviv Raff). Click the big button in the demo and the app drops a file (named “Free Coupwns!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.jar”) in the Chrome download folder. For me, this folder defaulted to c:temp. ZDNet says that some users are reporting the file on their desktop, so perhaps Chrome makes the desktop the download location some times. Note that this PoC belies the general notion that the jail/sandbox blocks file system access.
It also reports that the Chrome user-agent string identifies it as “AppleWebKit/525.13” (my full Chrome user-agent is “Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13”. Apple fixed the Carpet Bombing bug in a slightly later version. You see this sort of old version nonsense in open source a lot.
All of this goes to show that architecture can mitigate security bugs, but it can’t eliminate them. Still, architectural changes in browsers can make a big positive difference in security and I applaud Google for trying. Have they actually accomplished what they have set out to do? That will take more than zero-day hacking to demonstrate. Will Chrome be good enough that users will go to the effort of installing and using it? That’s a hard thing to do.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog