In the sandbox

Since its release a few weeks ago, curious developers have been sniffing through the source code for Google's new Chrome web browser. Chrome's source is interesting for a variety of reasons: there's the new V8 JavaScript virtual machine with its boasts of near-native code performance, the WebKit rendering engine that does all the hard work of understanding and displaying web pages, and (last but not least), Chrome's secure sandbox designed to minimize the impact of any security flaws that might exist in both the browser and plugins alike. It is this secure sandbox that has piqued the curiosity of some observers, and for a reason that many may find surprising. From reading the source, it looks as though Google has reverse-engineered Windows, and that's explicitly prohibited by the Windows EULA.

But before looking at the question of disassembly, it's worth taking a look at how Chrome is put together and at why its security architecture is interesting.

Chrome's security architecture

Of all the things that Chrome brings to the web browser market, its security architecture is the most unusual and significant. Traditional browsers (Firefox, Internet Explorer 7 and below, Opera, Safari) all create a single process for doing everything—displaying the user-interface, connecting to the Internet, parsing HTML, running plugins—and they share this process across all the tabs within the browser.

This one-process-for-everything model has a number of repercussions, the most obvious and most frustrating of which is that a crash in one tab (perhaps due to a bug with the browser's rendering engine itself, or perhaps due to a plugin) will crash the entire process, taking out all the tabs and destroying any work that the user is doing in an open tab. This architecture also has a number of other undesirable aspects that are less obvious. There's no particular reason that the "risky" pieces of code (the parts that have to deal with potentially malicious web pages or run plugins) should be able to read or write to the filesystem, for example; no reason, except that since some parts of the browser must be able to do so (to save downloaded files, say), the single-process model means that all parts of the browser can do so.

Redmond led the way

Windows Vista and Internet Explorer 7 have actually beat Google to the punch in making the first small step away from this single-process model. Internet Explorer has long had the concept of "security zones," which allow different security options to be applied to a local corporate intranet than to the global Internet. One long-standing source of bugs within Internet Explorer has been that a malicious web page can trick the browser into treating a web page from one zone as if it came from another (more privileged) zone. To address this vulnerability, Vista's IE7 prohibits the mixing of security zones within the same process. A browser open at the "Internet Zone" cannot then be used to open a page from the "Intranet Zone"; instead, a whole new iexplore.exe process is created, and the two are kept separate.

Internet Explorer 8, released as beta earlier this year, has moved even further from the monolithic model. Rather than one process per security zone, IE8 uses one process per tab, along with a parent process to control the user interface. This provides the separation that IE7 on Vista already had, plus a great deal more. With IE8, even tabs within the same security zone are independent and isolated from each other. This architecture also resolves the aforementioned long-standing problem with tabs, i.e., that one crashing tab destroys the entire browsing session. With IE8, one tab can crash and other tabs are unaffected.

IE8 and Data Execution Prevention (DEP)

The other major security feature of IE8 is its support for Data Execution Prevention (DEP), which is a feature designed to prevent buffer overflows from being able to inject executable code into a process. Traditionally on x86 processors, memory could be marked as readable-and-executable and/or writable; if memory was readable it could also be executed. This leads to exploitation through buffer overflows; a program allocates a temporary storage space (which must be both readable and writable so that the program can store some information and later read back that information), and a malicious attacker conspires to place a small piece of executable code into the storage space.

With DEP, readable and executable are no longer conflated; a piece of memory can be marked as readable and writable, but not executable. This provides an impediment to those wishing to overflow buffers for nefarious purposes. Unfortunately, there can be legitimate reasons to have memory that is readable, writable, and executable. One of these is just-in-time compilers, the kind of thing used by Java and .NET. These programs emit executable instructions at run-time, so they necessarily must be able to allocate memory that is writable, fill it with instructions, and then mark it as executable.

Although x86 has only recently supported independent settings of read, write, and execute permissions, the Win32 API has always supported the manipulation of these settings. Conscientious developers will have performed the correct manipulations even when it wasn't strictly necessary, to provide support both for non-x86 systems and for a future world (the one we now live in) where even x86 supports independent read and execute permission. Lazy developers, however, just blindly assumed that writable memory would be executable and so did not perform any of the permission setting that they now need with DEP. The result is that some older Windows programs crash when used with DEP, including a variety of ActiveX browser plugins.

To provide compatibility with these plugins, IE7 by default opted out of using DEP. In the time since IE7's release, some of the more important plugins have been updated to be compatible with DEP, and so IE8 now defaults to using DEP.

Which brings us neatly to Chrome. Just as with IE8, Chrome creates a process per tab. In fact, Chrome goes further in that it creates a process for each plugin, too. And just as with IE8, Chrome enables DEP for all its processes. It's this latter decision that has raised some eyebrows.