Reviews: Gazelle

[Rodrigo Fonseca]

Hi,

Please post your reviews of Gazelle as a reply to this message.

Thanks,
Rodrigo

[Duy Nguyen]

Paper Title 

The Multi-Principal OS Construction of the Gazelle Web Browser 

Author

Wang, Helen J., Grier, Chris, Moshchuk, Alexander, King, Samuel T., 

Choudhury, Piali, and Venter, Herman 

Date 

USENIX Security Symposium 2009 

Novel Idea

A new architecture for browser focusing on security. It isolates web

principals (web origins) into separate protection domains (OS processes).

The browser kernel also runs in a separate protection domain, interacts

with the underlying OS directly, and expose a set of system calls for

web principals. Web principals communicate to each other through browser

kernel using inter-process communication.

Main Result

Though it's just a research prototype, Gazelle is usable with acceptable

performance when browsing Top Alexa web sites.

Impact

This work is promising, especially when security is always a hot issue in

the web world.

Evidence 

Gazelle is evaluated on responsiveness, memory overhead, latency and process

creation. IE and Chrome are used for direct comparisons. In genaral, Gazelle

is slower and consumes more memory than those two.

Prior Work 

IE8, Google Chrome, OP

Competitive work

Chrome 

Reproducibility

The main ideas are clear enough but I think we still need some details to

reproduce this work.

Question

May be not relevant, but what makes NYT site consume too much memory?

[Basil Crow]

Title: The Multi-Principal OS Construction of the GazelleWeb Browser

Authors: Helen J. Wang, Chris Grier, Alexander Moshchuk, Samuel T. King, Piali Choudhury, and Herman Venter

Date: Microsoft Research whitepaper, 2009

Novel idea: The authors succinctly state that "it is realistic to turn an existing browser into a multi-principal OS that yields significantly stronger security and robustness with acceptable performance." In this case, a principle is defined as <protocol, domain-name, port>.

Main results: The authors' design features a browser kernel, which mediates the principals' access to system resources and enforces security polices. The authors then implemented their design on top of the Windows Vista and Internet Explorer codebases. In doing so, they had to deal with nontrivial issues regarding cross-principal/cross-process display and events protection.

Impact: There may be a market for hardware and software that is to be used exclusively for web applications.

Evidence: The authors tested their implementation with the top 20 Alexa web sites. They also measured page loading latencies, the memory foot print, and responsiveness of their prototype in comparison with IE7 and Google Chrome. They believe their implementation provided acceptable performance.

Prior work: The paper builds on the architectural improvements for browsers that begun with Google Chrome.

Competitive work: Wikipedia compares Gazelle to Chrome as follows: "Rather than the operating system being reduced in role to that of a browser, the browser [is] strengthened using operating system principles."

Reproducibility: The implementation is described well enough on a high level. With a solid engineering team, it should be possible to reproduce the results using alternative kernels and rendering engines. That having been said, few of us have that luxury.

Praise: It's impressive to see Microsoft innovating in the browser space again.

[Shah]

Title:

The Multi-Principal OS Construction of the Gazelle Web Browser

Authors:

[1] Helen J. Wang
[2] Chris Grier
[3] Er Moshchuk
[4] Samuel T. King
[5] Piali Choudhury
[6] Herman Venter

Source and Date:

TechReport. 19 February, 2009.

Novel Idea:

The authors present Gazelle - the only secure web browser to date that
implements a multi-principal OS.

Main Result:

The scientists present a browser kernel operating system that offers a
significantly higher level of protection than today’s designs.
Specifically, they expose intricate design issues such as cross-
protection-domain display and events protection.

Impact:

Since this paper is still in the form of a technical report, it has
been cited only some 10’s of times. Maybe when the authors publish
this as a research paper, it will grow in popularity since the idea
the authors put forth seems novel and interesting.

Evidence:

In Section 8, the scientists present evidence to support their claims.
Specifically, they conduct experiments to test page load latency and
memory overhead. Also, they conduct their experiments on a single
machine.

Prior Work:

In Section 2, the researchers give a list of all related work. Since
the idea is itself is novel, there’s strictly no prior work.

Competitive Work:

In the same section as above the researchers list two other browsers -
Google Chrome and IE 8 - that are concurrent. They list out the
weaknesses of the former and conclude the section by noting that both
Chrome and IE have different goals than does Gazelle. Indeed, they
state that Gazelle’s aim is to offer a high level of protection by
bringing in the paradigm that browsers are operating systems too.

Reproducibility

The scientists don’t provide enough information to make their
experiments reproducible. Critically, all the code is proprietary and
so it’s not possible to conduct the experiments the authors detail.

Questions:

[1] Do the authors plan on making this technical report into a paper
at some point?

[2] Is Microsoft going to phase out IE and perhaps introduce Gazelle?

Criticism:

As with proprietary papers, the scientists don’t provide enough detail
to make the experiments reproducible.

Ideas for Further Work:

The authors state in Section 10 that, in the future, they hope to
explore the fair sharing of resources among web site principals and
browsers. Also, they hope to conduct a thorough study of trade offs
between compatibility and security.

[Tom Wall]

The Multi-Principal OS Construction of the GazelleWeb Browser

Helen J. Wang, Chris Grier, Alexander Moshchuk, Sam King, Piali
Choudhury, and Herman Venter
2009

Novel Idea:
They create and evaluate Gazelle, a protoype multiprocess browser
which like Chrome attempts to isolate and secure the browser. Using an
approach similar to an OS kernel, the browser kernel process retains
exclusive control over all browser resources and exposes these
resources to principal sites and plugins through a system call
interface.

Main Result:
They implement Gazelle, reusing many components of IE7. There are some
compromises in their layering and rendering system to remain backwards
compatible, but overall it does a good job of keeping things separated
and secure. Their evaluation shows that there is some overhead, but
they claim much of it can be optimized away.

Evidence:
They attempt to use popular websites and then note the performance and
compatibility differences compared to IE7 and Google chrome.

Impact:
The browser as an OS is a nice concept, but it seems unlikely that
Gazelle ever see mainstream usage. It might be interesting to see how
Gazelle compares to Google's Chrome OS

Reproducibility:
Not reproducible. They don't mention how they do their measurements
in section 8.

Similar Work:
They note several similarities to Chrome. However, they claim Gazelle
offers tighter control over system resources. IE8 is also similar,
though their model is even more coarse than Chrome's. They also
mention some security-oriented browsers such as OP, Tahoma and SubOS.
OP, they claim, suffers from being too disjointed - all components are
isolated in their own process without much benefit. Tahoma uses VMs to
separate web programs. SubOS uses a modified process per URL model and
does not support embedded principals.

Questions:
Might some of the stuff common to each principal be shared amongst
processes to save some memory? It seems wasteful to have a separate
parser, renderer, and JScript engine for each processes.

Criticism:
Evaluation was pretty weak. They are very quick to blame performance
problems on their lack of optimization. They come up with numbers
somehow that explain how they can save time in the rendering process
for the NYTimes page, but I find it hard to trust those numbers
without an explanation of their methodology. And some of their
optimizations seem infeasible or would require a lot more effort than
they hint at.

[Visawee]

Paper Title :

The Multi-Principal OS Construction of the GazelleWeb Browser

Author(s) :
Helen J. Wang, Chris Griery, Alexander Moshchukz, Samuel T. Kingy,
Piali Choudhury, Herman Venter


Date :
19 February 2009


Novel Idea :
A multi-principal OS for web site principals. It exclusively provides
cross-principal protection and fair sharing of all system resources.


Main Result(s) :
Gazelle is able to correctly render 19 out of 20 websites in the top
20 Alexa web sites. Another site experiences incorrect layout issues
(which the authors mentioned as fixable).
(1) Performance : Gazelle performs on-par with commercial browsers
while browsing within an origin. However, it introduces some latency
overhead for cross-origin navigation and rendering embedded cross-
origin principals.
(2) Memory overhead : Gazelle uses more memory than existing
commercial browsers especially when a page contains many cross-origin
frames.
(3) Gazelle does not experience difficulties when it creates many
processes during normal browsing.


Impact :
Gazelle brings significant reliability and security benefits to the
overall browser system. It isolates a failure of a principal from the
others. It also enhances security on cross-principal websites.


Prior Work :
The prior works are mainly Monolithic browsers which are prone to
robustness, performance, and security issues.


Competitive Work :
(1) Chrome : Chrome and Gazelle is similar in the sense that they use
multi-process architecture. However, their principal granularity and
security policy are different. While Chrome aims toward performance,
Gazelle aims more toward about security and reliability.
(2) IE8 : IE 8 is also a multi-process browser like Gazelle. However,
the use of multiple processes in IE8 is for failure containment across
the user’s browsing sessions rather than for security.


Evidence :
The authors manually check the correctness of the top 20 Alexa
websites rendered by Gazelle. They also set up experiments comparing
between Gazelle, Chrome, and IE8 for performance and memory overhead.


Reproducibility :
The results are reproducible if given Gazelle’s source code.


Criticism :
- The authors mentioned a lot about Gazelle’s benefits regarding
security issues. However, they did not give experimental results to
support those claims.
- The authors should give test results of using Gazelle opening
multiple websites at the same time.
- The authors should use the same approach as in Chromium paper for
avoiding network variance. (All of the network requests in the tests
in Chromium paper were played back from disk from a previously
recorded browsing session)

On Nov 15, 7:48 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote:

[Sandy Ryza]

Title:
The Multi-Principal OS Construction of the Gazelle Web Browser

Authors:
Helen J. Wang, Chris Grier, Alexander Moshchuk, Samuel T. King, Piali

Choudhury, Herman Venter

Novel Idea:
The authors define the notion of a web principal as the set of browser
resources associated with a site (domain name, port, and protocol),
and present a browser architecture that segregates principals into
separate protection domains. Protection domains function on top of a
browser kernel like processes function on top of an OS kernel , and
interact with it through syscalls, centralizing all security decisions
and isolating the compromise of a single principal from other ones.

Main Result(s):
The authors find that as long as their browser kernel is not
compromised, the compromise of a principal does not affect any other
part of the browser, solving cross origin vulnerabilities, display
hijacking vulnerabilities. Their isolation also applies to plugins
and mitigates the effects of compromised plugins. In their
implementation, performance (compared to Google Chrome and IE 7)
suffers both in terms of latency, which roughly doubled for most tasks
related to navigating to new pages, and in terms of memory usage,
which was increased by an even more significant factor.

Evidence:
The authors survey common security vulnerabilities in Firefox 2 and
discuss which ones their architecture solves. They compared the
performance of the prototype they implemented with that of Google
Chrome and IE 7 for tasks such as opening a new blank tab, opening a
web page in a new tab and navigating from web pages to other pages.
They did not import any plugins to their system or run tests with
them.

Prior Work & Competitive Work:
The OP web browser segregates browser components such as HTML engine,
JavaScript interpreter, and rendering engine, in their own processes.
It solves many of the same security vulnerabilities that Gazelle
does. Tahoma makes use of VMs to isolate browser parts. Google
Chrome segregates site instances into different processes but does not
provide the notion of a browser kernel or protection domains and thus
does not provide them same security guarantees that Gazelle does.

Reproducibility:
The authors provide a detailed description of how they implemented
their prototype, but neither the IE code that they rely on nor their
code is publicly available.

Criticism:
Their justification for why SOP should be enforced on plugin content
was not very thorough. I admit to not knowing that much about the
area, but it seems very possible to me that plugins might need to have
access to resources that web sites should not.

Question:
What kinds of attacks exploit memory vulnerabilities? How do they
work?

On Nov 15, 7:48 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote:

[James Chin]

Paper Title: “The Multi-Principal OS Construction of the Gazelle Web
Browser”

Authors(s): Helen J. Wang, Chris Grier, Alexander Moshchuk, Samuel T.
King, Piali Choudhury, and Herman Venter

Date: 2009

Novel Idea: This paper presents Gazelle, a secure web browser with a
browser kernel as a multi-principal OS that exclusively manages
resource protection and sharing across web site principals. No
existing browsers, including new architectures like IE 8, Google
Chrome, and OP, have such a construction, as they all allow cross-
principal protection logic to reside in the principal space. Also,
Gazelle’s construction exposes challenging design issues that were not
seen in previous work, such as providing legacy protection to cross-
origin script source and cross-principal, cross-process display and
event protection. The authors are the first to provide comprehensive
solutions to them.

Main Result(s): The implementation and evaluation of Gazelle, an IE-
based prototype, shows that it is realistic to turn an existing

browser into a multi-principal OS that yields significantly stronger

security and robustness with acceptable performance. In such a
browser, the compromise or failure of a principal affects that
principal alone, leaving other principals and the browser kernel
unaffected.

Impact: Future web browsers or versions of existing browsers may adopt
Gazelle’s multi-principal OS construction.

Evidence: The authors evaluated Gazelle’s performance by measuring
page load latencies, the memory footprint, and the responsiveness of
their prototype in comparison with IE7, a monolithic browser, and
Google Chrome v1, a multi-process browser. They found that while

Gazelle performs on-par with commercial browsers while browsing within

an origin, it introduces some overhead for cross-origin navigation and
rendering embedded cross-origin principals, like frames. Despite
this, their main sources of overhead stem from their interposition
layer, various initialization costs for new browser instances, and the
unoptimized nature of their prototype. They point out simple
optimizations that would eliminate much of the overhead along the way.

Prior Work: No existing browsers, including new architectures like IE
8, Google Chrome, and OP, have such a construction, as they all allow
cross-principal protection logic to reside in the principal space.

Competitive Work: Chrome and IE 8 have different goals from that of
Gazelle. Their use of multiple processes is for failure containment
across the user’s browsing sessions rather than for security. In
addition, in the OP web browser, although intimate interactions
between browser components, such as the JavaScript interpreter and
HTML engine, must use IPC and go through its browser kernel, the
additional IPC cost does not add much benefits: isolating browser
components within an instance of a web page provides no additional
security protection. Furthermore, the Tahoma browser doesn’t provide
protection to existing browser principals, as its web application
manifest files typically contain suites of websites of possibly
different domains. Finally, the Building a Secure Web Browser project
uses SubOS, which does not handle embedded principals, unlike Gazelle.

Reproducibility: The findings appear to be reproducible if one follows
the testing procedures outlined in this paper and has access to the
code for Gazelle.

Question: Is Microsoft planning on incorporating Gazelle’s multi-
principal OS construction in the next version of Internet Explorer
(10)?

Criticism: Gazelle is built on Internet Explorer, which is notorious
for being perhaps one of the slowest, most non-secure browsers in
existence (although IE 9 looks promising, though).

Ideas for further work: Explore fair sharing of resources among
website principals in Gazelle’s browser kernel; perform a more in-
depth study of the trade-offs between compatibility and security in
browser policy design.

On Nov 15, 7:48 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote:

[Abhiram Natarajan]

Paper Title: The Multi-Principal OS Construction of the Gazelle Web
Browser

Author(s): Helen J. Wang, Chris Grier, Alexander Moschuk, Samuel T.
King, Piali Choudhury, Herman Venter

Date: 2009, SSYM

Novel Idea: Putting web site principals into separate protection
domains, completely segregating their access to all resources; and
thus exposing a set of system calls for web site principals.

Main Result(s): Gazelle, a secure web browser constructed as a multi-
principal OS.

Impact: A realistic chance to turn an existing browser into a multi-

principal OS that yields significantly stronger security and
robustness with acceptable performance.

Evidence: The authors implement a prototype and perform thorough
evaluation.

Prior Work: Google Chrome, IE 8, Experimental Browsers like the OP web
browser, Tahoma, Secure Web Browser project

Competitive Work: The authors measure Gazelle’s performance by
evaluating page loading latencies, the memory footprint, and
responsiveness in comparison with IE7, a monolithic browser, and
Google Chrome.

Reproducibility: Could be done. The architecture is explained in
pretty good detail.

Criticism: They should have compared themselves to Opera. From what I
know it is one of the most secure browsers. Nice side-step!

Question: Has anyone tried it?

On Nov 15, 7:48 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote:

[Zikai]

Paper Title: The Multi-Principle OS Construction of the Gazelle Web
Browser

Author(s):
Helen J. Wang (Microsoft Research)
Chris Grier
Alexander Moshchuk
Sam King (UIUC)
Piali Choudhury
Herman Venter (University of Washington)

Date/Conference: 18th USENIX Security Symposium (USENIX Security '09)

Novel Idea:
(1) Construct a secure web browser as a multi-principal OS for web-
site principals, i.e. the browser kernel is an operation system that

exclusively manages resource protection and sharing across web site
principals

(2) Propose novel mechanisms to provide legacy protection to cross-

origin script source and cross-principal, cross-process display and
event protection

Main Results:
(1) Design and implement Gazelle, a multi-principle OS construction of
a secure web browser.
(2) Perform a security analysis for Gazelle on how it handles several
kinds of common browser vulnerabilities: cross-origin vulnerabilities,
display vulnerabilities, plug-in vulnerabilities, memory attacks and
so on.
(3) Evaluate Gazelle’s performance overhead to achieve security and
robustness. Specifically page load latency, memory overhead and
responsiveness are used as performance metrics to compare with
Microsoft Internet Explorer 7 and Google Chrome in several scenarios.
The overhead is then further broken down to several causes.

Evidence: (1) Security analysis in Part 6
(2) Evaluation of latency/memory overhead in Part8.

Prior Work:
Same-Origin Policy (SOP) [39], Google Chrome’s site instance [37],
Native Client [47], Xax [15], .NET framework [4]

Competitive Work: Google Chrome [37], IE8 [25], OP web browser [21],
Tahoma[11], Building a Secure Web Browser project [27,28]

Reproducibility: It is hard to reproduce Gazelle because the paper
only covers general design points. Moreover, implementation requires
modifying IE8 which needs information only available inside
Microsoft.

Question: Is the multi-principal OS construction the only way to
achieve strong security and robustness? If other ways like current
sandbox model can be extended for so, it may be not worthwhile to
sacrifice performance so much.

Criticism: Main problem of the paper is that the evaluation part only
tests performance overhead. For security and robustness which are main
objectives of the design, only static analysis is done. It will be
better if they also evaluate various security and robustness scenarios
on their implementation.

On Nov 15, 7:48 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote:

[Hammurabi Mendes]

Paper Title

The Multi-Principal OS Construction of the Gazelle Web Browser

Authors

Helen J. Wang, Chris Grier, Alexander Moshchuk, Samuel T. King, Piali
Choudhury, Herman Venter

Date

USENIX Security'09

Novel Idea

Implementing the web browser with a central component that manages the
resource sharing among isolated web sessions.

Main Results

The paper presents Gazelle, a research browser implemented like a
multi-principal OS, managing the resources shared among the processes
in an exclusive and isolated manner (in other words, the managing
logic is located in a single place, and outside the address space of
the managed sessions).

Impact

1- The description and evaluation of a secure architecture for web
browser development. 2- Elucidate (directly or indirectly) the
possible compatibility impact of this (and similar) design structure
on current web pages.

Evidence

The paper first contrasts the security model of Gazelle versus the
security model of some current browser implementations. They discuss
the security advantages of the security model/system architecture
while these two topics are discussed, but they also have another
section in which they make higher-level comments about the issues
involved.

In their evaluation section, they discuss about time to load, required
memory, number of processes created. They also show which actions are
responsible for different partitions of the overhead. They have some
problems, which are discussed on the Questions + Criticism section.

Prior Work + Competitive Work

Primarily, they mention Google Chrome and IE8 as they isolate web
sessions by means of OS processes. However, they clearly mention that
these two browsers are more concerned with fault tolerance than with
credential management (in the sense of proper isolation and access
control).

They mention that OP has a similar architecture, but they argue that
it "does not provide all the cross-principal protection needed [...]",
saying that display management is relied to the processes.

They also talk about Tahoma, but they also argue that it doesn't
correctly isolate the principals (as many sites could share
information).

Another project is mentioned - Building a Secure Web Browser project -
but the authors say that it is not concerned with protecting
cross-section resource sharing (and display sharing, in particular).

Reproducibility

The experiments are reproducible. They are very simple and
straightforward. (Such simplicity is actually discussed in the next
section.)

Questions + Criticism

[Criticism] The evaluation section is actually concerned about
measuring time to load, memory required and number of process
creations. The first two metrics are discussed in the context of two
sites only. The third uses the top 100 from Alexa. I believe that the
first two measures are too restricted on the evaluation, as these
issues are still not clear for me:

[Question] Would the browser respond with more time or memory than
"necessary" depending on any particular web site configuration (number
of embedded components, number of external references, "image-farming"
(as the skyrock.com example for the evaluation of the third metric)?
By the way, what is an image farm?

[Question] Would there be any objective way to evaluate security in
this case except from argumentation? Anyway, the paper evaluate impact
objectively (and have the issues above), and evaluate security by
arguments (which appears reasonable to me).

On Mon, Nov 15, 2010 at 7:48 PM, Rodrigo Fonseca
<rodrigo...@gmail.com> wrote:

[Siddhartha Jain]

Novel Idea:
The idea is to make the browser a multi-principal OS for much stronger security and robustness. The principal is the
<protocol, domain, port>

Main Results:
The framework is described. A performance analysis is given.

Evidence:
The performance analysis tests latency and memory footprint. While the latency is only a little worse, the the memory consumption
seems a lot worse.

Reproducibility:
The framework is not described in enough detail to be able to reproduce results easily.

Competitive Work:
Chrome implements a similar design where pages are grouped by site and run under the same process. However Chrome does not
focut on security. In addition the way pages are grouped is different under Chrome vs. Gazelle.

Criticism:
The security analysis could be much better.

On Mon, Nov 15, 2010 at 7:48 PM, Rodrigo Fonseca <rodrigo...@gmail.com> wrote:

[Joost]

Title: The Multi-Principal OS Construction of the GazelleWeb Browser

Authors: Helen J. Wang¤, Chris Griery, Alexander Moshchukz, Samuel T.
Kingy, Piali Choudhury, Herman Venter
Date: USENIX 2009

Novel Idea: The authors propose a new browser in which all of the
processes are run through a browser kernel. Each separate domain is
partitioned separately and must communicate through the kernel to
reach other domains. The idea behind doing this is massively
increasing browser security.
Main Results: The authors successfully implemented a prototype of
this web browser framework, with compatibility for 19 of the top 20
trafficked sites according to Acela.
Impact: This research lays the groundwork for future web browser
developments, where the focus of production lies in browser security.
However, the prototype as it stands is rather bare bones, needs
backward compatibility to match today's web, and causes a significant
performance hit to usage compared to other browsers on the market.
Evidence: Authors demonstrated how the new implementation removes
sources of attack from areas such as cross-origin vulnerability,
display vulnerability, and plug in vulnerability completely. These
vulnerabilities consititute a significant share of all
vulnerabilities. In terms of usage testing, they ran a browser load
comparison between Gazelle, IE 7, and Chrome, and found that overall
memory usage was significantly higher and load times significantly
longer for Gazelle compared to Chrome, and a mix of similar and
inferior to IE 7.
Prior Work: Chrome, IE 8, Tahoma
Reproducibility: Lacking the implementation of Gazelle, it would be
rather difficult to reproduce these findings given that Gazelle is
built on IE libraries which are owned by Microsoft.
Question/Criticism: A useful test or experiment would have been a
sampling of thousands of websites and checking to see what the ratio
of vulnerabilities that got through the browser where for the
different systems.

On Nov 15, 7:48 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote: