Chrome Attic - a look at the source code

In the sandbox

Since the release last a few weeks ago, curious developers have been studying the source code of the new browser from Google. Chrome's sources are interesting for many reasons: here is the new V8 JavaScript machine with good performance gains in some tasks, the WebKit engine that processes and displays web pages, and finally the sandbox that isolates components in Chrome from each other. This system has attracted the attention of many programmers, for a simple reason. When reading the source, it seems that Google has decompiled (reverse-engineered) Windows components - and this is prohibited by the license agreement.


')
But before we consider the question of reverse engineering, it is worth looking at the browser itself.

Chrome Security Architecture

Of all the innovations of the browser, its security architecture is the most interesting and significant. Traditional browsers (Firefox, Internet Explorer 7 and below, Opera, Safari) create one process for everything - displaying the interface, connecting to the Internet, parsing HTML, launching plug-ins. All browser tabs use this process.

This “one process” model has many flaws, the most obvious of which is that it costs something to go wrong (a drawing engine bug or one of the plugins), and the browser is sent to digital Valhalla in its entirety. This architecture also has less noticeable features. For example, ideally, code running in plugins or the JavaScript engine should not have access to some resources — for example, write files to disk. But since all the components are executed in the same process, it is not easy to ensure this behavior.

Redmond is ahead again

Windows Vista and IE7 are actually ahead of Google in deviating from such a model. In Internet Explorer, the concept of " security zones " has been used for a long time, allowing to differentiate privileges for the intranet and the global network. One of the constant sources of bugs in IE was that a specially crafted page could “trick” the browser and run as if it were in a trusted zone. To get rid of this problem, in Vista it is forbidden to mix sources from different zones in the same process. If, after viewing sites from the Internet zone, you open an internal corporate site, a new instance of the iexplore.exe process is created, and they operate separately.

Internet Explorer 8, released as a beta release this year, has progressed even further in this direction. Instead of one process per zone, IE8 uses one process per tab, plus one parent process responsible for the interface. This provides even better insulation. In IE8, even tabs within the same security zone are independent and isolated from each other. This architecture solved another long-standing problem - now the sudden death of one tab does not affect the rest.

IE8 and Data Execution Prevention (DEP)

Another feature of IE8 - DEP support - data execution prevention, designed to be done once and for all with code execution during buffer overflow. Traditionally, in the x86 architecture, memory can be marked as read-and-execute and / or write. If read only was allowed, execution is allowed. This led to the ability to do buffer overflow - request memory for temporary storage (read and write are set to it), and place a small piece of executable code there.

With DEP, reading and writing are no longer related; the memory area can be marked as “read + write”, without the execution flag. Unfortunately, sometimes it is necessary to create areas where "read + write + execution" is allowed. A common case is JIT (just-in-time) compilers, such as Java and .NET. These programs can create executable code during execution, so they need to allocate memory, write information there, and then mark the area for execution.

Although normal support for DEP appeared relatively recently in x86, the corresponding functions have long been supported in the Win32 API. Conscious developers correctly handled DEP even if it was not strictly required to ensure compatibility not only with old processors, but also with future processors (on which we are currently working). However, lazy developers simply scored on such an “optional” thing. Therefore, some old Windows programs cannot run with DEP - including some ActiveX plugins.

To ensure compatibility with these plugins, the developers of IE7 have turned off DEP support by default. Since the release of this browser, many plugins have already been updated (the developers realized that very soon this will become a mandatory requirement), and IE8 already includes DEP by default.

Which brings us to Chrome. Like IE8, Chrome creates one process for each tab . In fact, it goes even further, creating an additional process for each plug-in. And, like IE8, Chrome includes DEP for all its processes.

Where is reverse-engineering, you ask? If you delve into the source code of Chrome, you can see an interesting thing.

Chrome first tries to use the standard API to manage DEP. However, if this fails, he tries the second method:

// Completely undocumented from Microsoft. You can find this information by
// disassembling Vista's SP1 kernel32.dll with your favorite disassembler.


(quote from browser code).

Most of the functions used are fully officially documented - for example, CreateProcess is described very well. NtQueryFullAttributesFile is an undocumented function. To create processes in Chrome are used, and those and others.