By Sterling “Chip” Camden
Contributing Writer, [GAS]

You must be wondering how you entered a parallel universe in which a [GAS] headline can include the words “Microsoft”, “browser”, and “secure” — without the words “not”, “disaster”, or “joke”.  And given the history of security flaws in Internet Explorer over the years, the folks at Redmond need to put a whole lot of money where their mouth is when they claim to be developing a browser that implements a better security model than Firefox, Google Chrome, or even OP (PDF).  But that’s exactly the claim of a team at Microsoft Research, where they’ve developed a prototype and written a paper (PDF) about a proposed web browser they call “Gazelle.”

Both Chrome and OP have already explored the idea of achieving greater security and reliability by creating separate processes to manage different concerns within the browser.  Gazelle uses the same idea, but draws the lines between processes a bit differently.  In Gazelle, the Browser Kernel (BK) manages all direct access to the operating system and the network.  Individual page-rendering processes may only access these resources indirectly, via an API through the BK.

Gazelle also strictly enforces process separation along same-origin policy (SOP) lines.  If you have a web page that embeds an iframe that’s sourced from a different domain, for example, Google Chrome hosts that entire page including the iframe within the same process.  In Gazelle, each domain-host-protocol source gets its own process.  The process for the iframe renders the display for the area that it occupies as a “tenant”, but has no access to any part of the page outside that area.  The main page, or “landlord”, manages the dimensions of the iframe, but has no access to the content within it.  Neither process manipulates the screen directly — that’s relegated to the BK.

Gazelle’s SOP rules are also more strict than those of existing browsers.  Subdomains are not considered the same origin as their parent domain — so a script hosted at scripts.mydomain.com would not have access to elements of a page hosted at mydomain.com, for instance.  However, a path (e.g., mydomain.com/scripts) would still be considered part of the same origin.

Unlike the OP browser, Gazelle does not separate JavaScript, CSS, and HTML handling into separate processes.  Microsoft researchers feel that such a separation adds no real security benefit, while adding a significant interprocess communication overhead.  So Gazelle combines everything required to render content from a single source within a sandboxed process.  That process is paired with a sandboxed instance of browser plugins to form what is called a “principal”.  Principals can communicate with the BK and with each other, but only through the defined API.  Plugins operate under the same source restrictions as web content, so they only have access to page content that comes from the same origin as the plugins themselves.

The team has put quite a lot of thought into how to handle user-generated events as well.  In general, a mouse click for example gets forwarded to the principal in charge of the area occupying that screen real estate.  Topmost window wins, and every principal’s assigned area must be opaque — eliminating many types of clickjacking vulnerabilities.

The prototype version of the browser reportedly works reasonably well — the team has identified many areas for improvement, but it displayed 19 out of the top 20 Alexa-ranked sites without any issues.  Performance will need work — which shouldn’t be a surprise given the design of the prototype:  the BK is written in C#, and the browser instance is a Trident WebControl wrapped in an “interposition layer” of code that prevents the WebControl from doing anything directly with the system or the network.  We can only hope, should Gazelle become a production browser, that Microsoft would abandon Trident in favor of a more standard and better-performing rendering engine.

Source: The Multi-Principal OS Construction of the Gazelle Web Browser (PDF)