The Chrome development team focused on three things; stability, speed, and security. Chrome is stable and fast, but how do we know if it's secure?
Determining if something is secure can be difficult. Fortunately, software has the advantage of testing regimens like the Pwn2Own contest. If the software has any weaknesses, the highly-qualified contestants will find them.
It took reading about this year's contest to convince me that Chrome is secure, and I needed to switch. I also started wondering what sets Chrome apart when it comes to security. After a little digging, I met Ian Fette of the Google Chrome team. He provided the needed insight:TechRepublic: It's been mentioned numerous times that security was a top priority when designing Chrome. Could you list the top three security concerns of the development team?
Fette: When building Google Chrome, we wanted to design the browser with security in-depth. We know that there isn't a single silver bullet to solve all security problems so we wanted to develop security functionality in all levels of the application. Three areas where we invested a lot of time were:
- Warn users when they were accessing an unsafe site.
- Work to keep untrusted code from leaving the browser's sandboxed renderer.
- Ensure that users always have the latest and most up to date version of the browser in as quick a time as possible.
To prevent untrusted code from leaving the renderer process we implemented what's known as a "sandbox" around the renderer. This added level of security makes it harder for an attacker to exploit code on your computer, because even if they find a vulnerability in the renderer, they still are stuck in the sandbox.
Finally, to ensure users are always up to date with the latest version of the browser, including having the most recent security patches, we developed an automated system that updates the browser in the background without any manual intervention.
In order to meet their goals, the Chrome development team decided to use what is called multi-process architecture.
By design, multi-process architecture splits the browser application into component processes. This way if one fails, the entire browser does not crash. Chrome is divided into the following processes:
- Browser: This process manages tabs, windows, and "chrome" of the browser. This process also interfaces with the hard drive, network, user input, and display.
- Plug-ins: By design, a process is created for each plug-in or extension that is in use.
Now, to some questions about multi-process architecture:TechRepublic: If I understand correctly, Google was the first to use multi-process architecture for Web browsers. How is Google's implementation different from other web-browser applications? Fette: Google took a novel approach by breaking down the browser into distinct components — the browser, the renderer, and plug-ins. When we launched, we were the only major browser with this approach, which gave us a number of advantages.
For instance, if a plug-in crashes, the page you are viewing stays visible and remains responsive, it's just the portion of the page being rendered by the plug-in that turns into a "sad" icon.
The policy we set on renderer processes prevents malicious code running in the renderer from doing either reads to or writes from the user's file system (desktop etc), registry, and more. This policy is stricter than other browsers shipping today, and also applies to Windows XP, which still has significant market share.TechRepublic: I remember being surprised at the number of processes Chrome can have open. Is there a limit to the number of web sites that can be open at the same time? If so what happens after the limit is reached? Fette: We limit the number of processes we will create, not the number of web sites you can open. We do this to achieve optimal performance tradeoffs, based largely on the amount of memory on your system (if you have more memory, we will limit the number of processes at a higher number).
Once you hit the limit on the number of processes, new tabs that you open will share a renderer process with other tabs. So, if you have 20 windows open with 20 tabs each, for a total of 400 tabs, it's possible that each renderer process might be supporting 10 tabs each, as opposed to overloading your computer with 400 different Chrome processes.
Besides stability, multi-process architecture affords another benefit. By design, individual processes are not dependent on each other and can be isolated in what Google calls Chrome sandboxes. The following analogy penned by Esalkin on the Sandboxie forum is a great way to explain sandbox applications to those not familiar with them:
"Think of your PC as a piece of paper. Every program you run writes on the paper. When you run your browser, it writes on the paper about every site you visited. And any malware you come across will usually try to write itself into the paper.
Traditional privacy and anti-malware software try to locate and erase any writings they think you wouldn't want on the paper. Most of the time they get it right. But first, the makers of these solutions must teach the solution what to look for on the paper and how to erase it safely.
On the other hand, a sandbox works like a transparency layer placed over the paper. Programs write on the transparency layer and to them it looks like the real paper. When you delete the sandbox, it's like removing the transparency layer, the real paper is unchanged."
Experts, such as Charlie Miller sees the use of sandboxes as the reason Chrome has not been exploited:
"They've got that sandbox model that's hard to get out of. With Chrome, it's a combination of things, you can't execute on the heap, the OS protections in Windows and the sandbox."
How the Chrome sandbox works
Remember the renderers that I mentioned earlier? They are the sandboxed processes in Chrome. Because they are in sandboxes, the only resources renderers (Web page tabs) can use are CPU cycles and memory. Examples of what renderers cannot do, would be write to disk or display their own window. Those tasks are controlled by the browser process.
In order to achieve this, Google Chrome uses the Windows security model based on access tokens. An access token consists of information about the process owner and the privileges the process has. After reading the access token, the operating system then knows what resources that particular process or sandbox can access. Here is Google's explanation:
"Before launching the renderer process we modify its token to remove all privileges and disable all groups. We then convert the token to a restricted token. A restricted token is like a normal token, but the access checks are performed twice, the first time with the normal information in the token, and the second one using a secondary list of groups.
Both access checks have to succeed for the resources to be granted to the process. Google Chrome sets the secondary list of groups to contain only one item, the NULL user. Since this user is never given permissions to any objects, all access checks performed with the access token of the renderer process fail, making this process useless to an attacker."How this helps
Plug-ins are not sandboxed right now, but we are working to bring them into the sandbox. Our recent announcement about integrating Adobe Flash into Google Chrome is a big step towards helping us operate Flash in the sandbox.TechRepublic: With regards, to Chrome sandboxes, I have read they work differently when using operating systems newer than Windows XP. Could you elaborate on that? Is there a benefit to using the newer OSs? Fette: In Vista and later, extra capabilities are introduced to lock down a process, namely "integrity levels." Chrome applies low integrity on top of the normal restrictions applied by the Chrome sandbox on both XP and Vista.
While this theoretically makes the Vista sandboxing capabilities stronger, we are not aware of any practical attacks against Chrome where this would have made a meaningful difference. However, it does provide another layer of defense, and so we do use the integrity levels on Windows versions where they are available, as a defense-in-depth practice.Final thoughts
I am no expert when it comes to Web browser design, but Charlie Miller is. If he can't exploit Chrome, that means something. I now have a better idea as to why he can't thanks to Google's Ian Fette. I also want to thank Eitan Bencuya of Google Communications, for connecting me with Ian.
Information is my field...Writing is my passion...Coupling the two is my mission.