U.S. patent application number 14/563712 was filed with the patent office on 2017-02-16 for systems and methods for an automatic fresh browser instance for accessing internet content.
The applicant listed for this patent is The Arizona Board of Regents for and on Behalf of Arizona State University. Invention is credited to RIDA A. BAZZI, MOHSEN ZOHREVANDI.
Application Number | 20170048298 14/563712 |
Document ID | / |
Family ID | 56095387 |
Filed Date | 2017-02-16 |
United States Patent
Application |
20170048298 |
Kind Code |
A9 |
BAZZI; RIDA A. ; et
al. |
February 16, 2017 |
SYSTEMS AND METHODS FOR AN AUTOMATIC FRESH BROWSER INSTANCE FOR
ACCESSING INTERNET CONTENT
Abstract
A system and method for securing access to sensitive content on
the web is disclosed. The approach automates compartmentalization
practices for accessing different kinds of content with different
browser instances. The automation is transparent to the user and
does not require any modification of how non-sensitive content is
accessed. For sensitive content, a Fresh Browser Instance (FBI) is
automatically created to access the content. In addition, the
automatic FBI system may provide support for novice users with
predefined sensitive content sites as well as for more experienced
users who can define conflict of interest (COI) classes which
allows content from sites in the same user-defined class to coexist
in a browser instance.
Inventors: |
BAZZI; RIDA A.; (Scottsdale,
AZ) ; ZOHREVANDI; MOHSEN; (Tempe, AZ) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
The Arizona Board of Regents for and on Behalf of Arizona State
University |
Tempe |
AZ |
US |
|
|
Prior
Publication: |
|
Document Identifier |
Publication Date |
|
US 20160164946 A1 |
June 9, 2016 |
|
|
Family ID: |
56095387 |
Appl. No.: |
14/563712 |
Filed: |
December 8, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61912716 |
Dec 6, 2013 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 21/52 20130101;
G06F 21/57 20130101; H04L 67/02 20130101; G06F 21/53 20130101; G06F
21/6263 20130101 |
International
Class: |
H04L 29/08 20060101
H04L029/08; G06F 21/52 20060101 G06F021/52; G06F 21/62 20060101
G06F021/62 |
Goverment Interests
GOVERNMENT SUPPORT
[0002] This invention was supported by funding from the Federal
Government through the National Science Foundation under
Grant/Contract No. CSR-0849980. The Government may have certain
rights in the invention.
[0003] Aspects of the present disclosure relate to a system for
securing access to sensitive content on the Internet, and in
particular to a system for accessing different kinds of content
with different browser instances.
Claims
1. An automatic fresh browser instance system allowing different
categories of content to be displayed in different independent
browser instances, the system comprising: at least one computing
device comprising: an enforcer to ensure that web content
satisfying two different categorizations is not accessed by a first
browser instance of a web browser; and an enabler to generate a
second browser instance of the web browser to access a portion of
the web content that satisfies one category of the at least two
different categories.
2. The automatic fresh instance browser system of claim 1, wherein
the second instance is launched automatically to a client device
for display.
3. The automatic fresh instance browser system of claim 1, wherein
to ensure that the web content satisfying two different
categorizations is not accessed by a first browser instance of a
web browser comprises executing an API call to intercept a system
call corresponding to the web browser.
4. The automatic fresh instance browser system of claim 1, wherein
the at least two different categories includes a sensitive
information category indicating that the portion of the web content
that presents a security risk.
5. The automatic fresh instance browser system of claim 1, wherein
to ensure that the web content from two different categories is not
accessed by the first browser instance of a web browser comprises:
executing a tracer to determine whether or not a requested network
object is allowed to be accessed by the first browser instance.
6. The automatic fresh instance browser system of claim 1, wherein
the enforcer further configured to prevent a browser instance from
communicating with a source that does not raise a conflict of
interest.
7. A method for allowing different categories of content to be
displayed in different independent browser instances, the method
comprising: verifying, using at least one computing device, that
web content satisfying two different categorizations is not
accessed by a first browser is not accessed by a first browser
instance of a web browser; and generating, using the at least one
computing device, a second browser instance of the web browser to
access a portion of the web content that satisfies one category of
the at least two different categories.
8. The method of claim 7, wherein the second instance is launched
automatically to a client device for display.
9. The method of claim 7, wherein to ensure that the web content
satisfying two different categorizations is not accessed by a first
browser instance of a web browser comprises executing an API call
to intercept a system call corresponding to the web browser.
10. The method of claim 7, wherein the at least two different
categories includes a sensitive information category indicating
that the portion of the web content that presents a security
risk.
11. The method of claim 7, wherein to ensure that the web content
from two different categories is not accessed by the first browser
instance of a web browser comprises executing a tracer to determine
whether or not a requested network object is allowed to be accessed
by the first browser instance.
12. The method of claim 7, wherein the enforcer is further
configured to prevent a browser instance from communicating with a
source that does not raise a conflict of interest.
13. A non-transitory computer readable medium encoded with
instructions for allowing different categories of content to be
displayed in different independent browser instances, the
instructions, executable by a processor, comprising: verifying that
web content web content satisfying two different categorizations is
not accessed by a first browser is not accessed by a first browser
instance of a web browser; and generating a second browser instance
of the web browser to access a portion of the web content that
satisfies one category of the at least two different
categories.
14. The non-transitory computer readable medium of claim 13,
wherein the second instance is launched automatically to a client
device for display.
15. The non-transitory computer readable medium of claim 13,
wherein to ensure that the web content satisfying two different
categorizations is not accessed by a first browser instance of a
web browser comprises executing an API call to intercept a system
call corresponding to the web browser.
16. The non-transitory computer readable medium of claim 13,
wherein to ensure that the web content from two different
categories is not accessed by the first browser instance of a web
browser comprises executing a tracer to determine whether or not a
requested network object is allowed to be accessed by the first
browser instance.
17. The non-transitory computer readable medium of claim 13,
wherein the enforcer is further configured to prevent a browser
instance from communicating with a source that does not raise a
conflict of interest.
18. The non-transitory computer readable medium of claim 13,
wherein the at least two different categories includes a sensitive
information category indicating that the portion of the web content
that presents a security risk.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims benefit to U.S. provisional
application Ser. No. 61/192,716 filed on Dec. 6, 2013, which is
incorporated by reference in its entirety.
BACKGROUND
[0004] Content delivered through web browsers continues to be a
major vector of attack in personal computing systems. A large
variety of attacks exploit what might be termed convenience
features of browser content. Executing scripts, such as JavaScript,
in web browsers enable a richer browsing experience and enabling
cookies allow for the convenience of maintaining a state across
multiple pages. Unfortunately, convenience features also enable
richer attack modalities. The tension between providing richer
content and providing security is real and it is not only due to
technical reasons; the more features a system has, the less likely
it is for a novice, or even for an experienced user, to get the
system settings right. Default browser security settings do not do
much to mitigate the situation. Unless security settings are
draconian in nature, such as disabling all active content for
example (which will also diminish the browsing experience) they do
not solve the problems introduced by these convenience features.
The possibility that a browser process is compromised by malicious
content increases with the usage of the process. The more sites are
visited, the more likely it is that malicious content is running in
the browser.
[0005] Accessing many sources of content on a browser may result in
a difficulty for the user to locate tabs and content. For example,
a user might have multiple windows open at a time and in order to
locate particular content might have to look in multiple windows,
which is tedious. A method is needed to facilitate the organization
of content in web browsers into different categories without extra
overhead incurred by the user.
[0006] It is with these concepts in mind, among others, that
aspects of the present disclosure were conceived.
SUMMARY
[0007] Aspects of the present disclosure include systems, methods,
and/or non-transitory computer readable mediums for automatic fresh
browser instance system allowing different categories of content to
be displayed in different independent browser instances. The
systems and/or methods include at least one computing device that
includes an enforcer to ensure that web content satisfying two
different categorizations is not accessed by a first browser
instance of a web browser and an enabler to generate a second
browser instance of the web browser to access a portion of the web
content that satisfies one category of the at least two different
categories.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIG. 1 are screen shots of a request to a third party entity
and a message display for the automatic fresh browser instance
(FBI) system;
[0009] FIG. 2 is a screen shot of two different browsers for the
automatic FBI system;
[0010] FIG. 3 is an example COI written by an experienced user;
[0011] FIG. 4 is a simplified block diagram of the automatic FBI
system;
[0012] FIG. 5 is TABLE 1 showing a performance evaluation for a
tracer;
[0013] FIG. 6 is a flow chart illustrating one method of using the
automatic FBI system for a novice user;
[0014] FIG. 7 is a flow chart illustrating another method of using
the automatic FBI system for an experienced user; and
[0015] FIG. 8 is a block diagram of a computing system.
[0016] Corresponding reference characters indicate corresponding
elements among the various views of the drawings. The headings used
in the figures should not be interpreted to limit the scope of the
claims.
DETAILED DESCRIPTION
[0017] Aspects of the present disclosure involve an automatic fresh
browser instance ("FBI") system ("FBI system") for implementing a
process that automates compartmentalization practices for accessing
different kinds of Internet content with different browser
instances. For example and in various aspects, the FBI system may
use system-call interception to restrict connections to web
servers, which requires tracing all system calls made by a given
instance of a web browser. In another example, the FBI system may
use browser extensions to obtain the URL that the browser is
attempting to access. Additionally, in order not to interfere with
browser functionality, sites for which access is restricted for a
given instance are serviced through a combination of DNS-query
rewriting and replacement of restricted pages with default pages.
In order to keep track of all active browser instances and their
conflict of interest ("COI") classes, a daemon outside the browser
keeps track of active instances and launches new instances as
needed. To communicate the URL of the website being accessed to the
daemon, an intermediate process forwards messages between the
browser extension and the daemon. Finally, to avoid buffer overflow
attacks, URLs may be read using constant-bounds while loops.
[0018] According to other aspects, the FBI system may automatically
launche an FBI whenever the current browser instance should not be
used to handle a requested website. The launched browser need not
be the same as its launcher; for example, the launched browser can
be Firefox while the launcher can be Chrome, for example.
[0019] Not all users are equally savvy in setting security
preferences. Accordingly, for certain FBI system users, such as for
example a or novice user, a default usage model may be employed
that allows safe browsing for and does not change the way users
access the Internet. Alternatively, for more experienced users, a
nuanced usage model is employed by the FBI system that allows users
to define simple yet powerful security preferences to allow them to
access multiple sites in the same conflict of interest (COI)
instance.
Contributions
[0020] In one embodiment, the FBI system provides protection
against information leakage (privacy protection) as well as
protection against some active attacks (integrity threats); such as
cross site request forgery and clickjacking attacks are prevented.
Stated differently, no unauthorized access to sensitive content can
be done using these attacks.
[0021] In another embodiment, the automatic FBI implements an
effective approach for providing secure access to sensitive content
for a novice user, while allowing an experienced user to specify
COI classes of content that can coexist in a browser instance.
[0022] The FBI system is as an effective, easy to use, and general
approach for providing secure access to sensitive content for
novice users. Unlike other approaches, the FBI system approach is
tolerant of privacy as well as integrity attacks while being
browser-independent.
System and Threat Model
[0023] The disclosed FBI system consists of a client side and a
server side. Web clients typically run in web browsers. Web
browsers retrieve web content delivered by web servers. Web servers
and web content have origins associated with them. Web content is
acted upon by the web browser. Content might be active which
requires the browser to execute some code to process it. The FBI
system includes or otherwise implements a browser that processes
content from a given origin to be a delegate of the origin. Web
content is retrieved using web queries, which can be a simple query
that specifies the address of the content in the form of a URL
(uniform resource locator) which consists of a domain name and file
path or an active query that consists of the above and parameters
that are passed to server-side code--scripts--that use the
parameters to process the query. A web server might require
credentials from a web browser in order to authenticate the
principal requesting queries. Credentials are typically provided
when initial access is requested, typically in the form of a login
id and password. Once credentials are approved, a cookie is stored
by the browser to be used for future authentication. At that point
the browser acts as a delegate of the authenticated principal.
[0024] An instance of a web browser is a software process that
executes the browser code and has associated with it a profile
which includes information such as preferences, browsing history,
cookies, bookmarks, and saved passwords. A profile captures an
execution state of the browser. When a browser exits, some
information might be deleted from the profile, non-persistent
cookies for example, but other information in the profile is saved.
When a browser is restarted after exiting, the profile provides
continuity between the old browser process and the new process.
[0025] Given that a browser instance can be processing content from
different sources, and therefore is a delegate for these sources,
it is important that these various roles do not get mixed together
in the browser. For example, a script running in a browser on
behalf of one source should not be able in general to read data
associated with another source in the browser--such as passwords
being entered in a form. Such restrictions are expressed as
security policies and are enforced by the browser. Unfortunately,
given the great flexibility provided by the browser, scripts have
the ability to obtain information indirectly through attempted
access to forbidden resources and to communicate directly and
indirectly with their origins. This flexibility makes it hard to
enforce policies and even when policies are correctly enforced,
they might still allow undesired behavior. Single Origin Policy
(SOP) is an example of a policy that can be circumvented rather
easily. In general, a security policy restricts what actions can be
done by the various system processes. Abstractly, one can think of
a policy as a set of allowed system executions. A policy for a web
browser expresses what executions of the browser are allowed and
which executions are not allowed as seen by an external observer.
In other words, a policy on a web browser is a restriction on the
input/output behavior of the browser.
[0026] A browser is susceptible to an attack relative to a security
policy if some browser executions do not satisfy the security
policy. Attacks are defined not in terms of the specific technical
modalities to achieve them, but in terms of what can be achieved.
In general, an attack requires the browser to get and process
content from one or more attack origins. In describing an attack
assume that there are at least three classes of origin: HIGH, LOW,
and AUTH (authenticated). Also assume LOW is disjoint with both
HIGH and AUTH, but HIGH and AUTH need not be disjoint. The
following are attack models detectable by the system(s) described
herein.
[0027] 1. Information Leakage (Leakage): An attacker is able to
launch an information leakage attack if a LOW origin is able to
receive content from a HIGH origin through the browser.
[0028] 2. Cross Site Request Forgery (CSRF): An attacker is able to
launch a CSRF attack if requests to an AUTH origin to which the
browser is already authenticated depends on content from a LOW
origin.
[0029] 3. Clickjacking (UI Redress): UI redress attack is similar
to CSRF attack, but requires user participation by interacting with
user interface elements. It is typically achieved by exploiting
features of the user interface to let a user interact with a target
website when they think that they are interacting with other
content.
Use Model
Novice User
[0030] A security mechanism has a better chance to be effective if
it is well understood and easy to use. This is especially true for
novice users. Accordingly, the FBI system enables the processing of
two types of sites for a novice user: sensitive sites and every
other type of site. Access to a sensitive site is done through a
dedicated FBI. Access to all other sites is done through separate
browser instance(s) as it would be done without Auto-FBI. When a
user attempts to access a sensitive website by clicking on a link
or entering a URL directly in the address bar, an FBI is created to
handle the access. When the user finishes accessing the sensitive
site, the user can close the FBI or minimize it. If the user later
attempts to access the sensitive site from another browser
instance, a new instance is activated again, or, if there is an
existing active instance for the site, that instance is used to
process the request. For added security, the FBI may be opened
without an address bar, menus or tabs to emphasize that the access
is meant for only one site. This simple usage model is preferable
to a model that requires the user to define security policies which
is not uncommon in mechanisms that are claimed to be
transparent.
[0031] Access for a novice user is illustrated in a process flow
600 of FIG. 6, with reference to the browsers depicted in FIGS. 1
and 2. Referring initially to FIG. 6, a user launches a first
browser instance at 602 and instructs the browser to retrieve a URL
at 604. Referring to FIG. 1, a request is made to
www.bankofamerica.com. Referring back to FIG. 6, the automatic FBI
system determines if the URL is sensitive at 606 and if so, the
automatic FBI system redirect the first browser instance to a
default page at 608. If the URL is determined not to be sensitive,
the first browser instance retrieves the URL at 616.
[0032] Referring back to FIG. 1, when a URL is sensitive, instead
of displaying the requested page in the current instance browser
102, the automatic FBI system displays a message at 104. In the
illustrated embodiment of FIG. 1, the message indicates that the
requested website handles sensitive information and that a new
browser window will be opened to handle the request for security
reasons.
[0033] Alternatively, instead of displaying a warning message, as
in the illustrated embodiment of FIG. 1, and to reduce mental
overhead on the user, no message is displayed in the current
instance.
[0034] Referring again to FIG. 6, a fresh second instance of the
browser is automatically launched by the FBI system without menus,
tabs, or address bars at 610 that retrieves the requested URL at
612. FIG. 2 illustrates that a requested page with sensitive
content may be accessed by a fresh instance 202 of a different
browser while the browser that made the original request displays a
warning message, as illustrated at 104. Referring back to FIG. 6,
once the URL has been served by the second instance, a user may
interact with the web content and/or web page presented through the
URL. In another embodiment, address bars and menus might still be
made available to the user.
Experienced User
[0035] For the experienced user, the FBI system allows content from
more than one domain to coexist within a browser instance. The idea
is to allow content originating from a conflict of interest (COI)
class to coexist within a browser instance. As an example, an
experienced user might define a COI class that contains some
specific financial institutions and another class that contains
some specific news sources. In a given browser instance, content
from sources that belong to the same COI class can coexist as
separate tabs or as content within the same page if a page links to
content from multiple sources in the same COI class. An experienced
user defines conflict of interest classes 300 in a classes file as
illustrated in FIG. 3. The file consists of multiple sections, one
for each COI class, but the first section specifies common domains,
such as certificate authorities, that should be accessible by all
COI classes. Each section starts with a line that defines the
browser to be used followed by one or more lines that list the
domains for the COI class. Any domain that does not appear
explicitly in one of the COI classes or the first section is
assumed to belong to an implicitly declared {\em general COI class.
When a browser is launched by the user, it is associated with the
general class. If the user attempts to access a site from a domain
in a class other than the general class, then, if there is no
active browser instance associated with that class, a new browser
instance for that class is created to process and display the site.
If there is an active browser instance for the class of the
requested site, then the request is processed and displayed in that
instance. To allow for using different browsers for different
classes, e.g. using Google Chrome for e-commerce and Mozilla
Firefox for banking, we specify the browser type rule that should
be followed for each class with a type descriptor (that comes
immediately after a in the sample file): [0036] `F`: Mozilla
Firefox instance should be used [0037] `C`: Google Chrome instance
should be used [0038] `=`: the launched browser instance should be
the same type as the launcher [0039] `!`: the launched browser
instance type should be different from that of the launcher [0040]
`_`: places no restriction on the type of the browser
[0041] The implicit general class has the implicit type descriptor
`_`, so both Google Chrome and Mozilla Firefox can be used to
browse websites from the general class. While Google Chrome and
Firefox have been provided as examples, it is contemplated that any
type of internet browser, or any browser accessible by a user, may
be used.
[0042] The example file shown in FIG. 3 has two explicit COI
classes (we will refer to them as C.sub.1 and C.sub.2 as shown in
the comments). The first class C.sub.1 302 has type descriptor `!`
and the second class C.sub.2 304 has type descriptor `C. To
demonstrate the user experience, let's consider the following
scenario: user opens Google Chrome to start browsing, an instance
of Google Chrome of the general class is created. The user can
navigate to any site that is not listed in C.sub.1 302 and C.sub.2
304 in that browser instance. If the user tries to navigate to
www.bankofamerica.com which is listed in C.sub.1 302, a fresh
instance of Mozilla Firefox will be created to handle the request.
That is because the type descriptor for C.sub.1 302 specifies that
an instance with a different type from that of the launcher (Google
Chrome in this example) should be used. If the user tries to access
www.facebook.com from the Mozilla Firefox instance, the request
will be handled by the existing Google Chrome instance of the
general class. That is because the general class has the implicit
type descriptor `_` which allows the system to use the available
instance. If the user navigates to www.ebay.com from any of the
previous instances, a new instance of Google Chrome will be
launched to handle the request regardless of the browser type used
to initiate the request.
[0043] Access for an experienced user is illustrated in a process
flow 700 of FIG. 7. As illustrated, at 702, process 700 begins with
a user launching a first browser instance (instance_1) that is
associated with the general class. The FBI system then receives
input requesting retrieval of a URL from a specific one of a set of
running browser instances, instance X, at 704. If the class
associated with instance X is the same as the class associated with
the URL at 706, the instance X retrieves the URL at 710. When the
class associated with instance X is not the same as the class
associated with the URL, the FBI system directs instance X to a
default page at 708. Subsequently, the FBI system determines
whether there is a different browser instance, instance Y that is
associated with the class of the URL at 714. If the class
associated with instance Y is the same as the class associated with
the URL, the FBI system sends a message to instance Y to handle the
URL at 716 and instance Y retrieves the URL at 720. When the class
associated with instance Y is not the same as the class associated
with the URL, the FBI system directs instance Z to retrieve the URL
at 718.
[0044] Thus the FBI system includes an enforcement mechanism with
the ability to prevent a browser instance from communicating with
sources that are not in its COI class and an enabler mechanism for
starting FBI's as needed. The FBI system involves three main
embodiments to provide the proposed functionality: (1)
functionality included inside the browser through modification of
the browser code; (2) functionality implemented as a browser
extension; and/or (3) functionality implemented outside the
browser. [0045] Enforcement inside the browser: The desired
functionality could be provided by modifying the browser to add the
desired enforcement rules. Enforcement in a browser extension: In a
typical web browse (e.g., Chrome) extensions may be a combination
of JavaScript and native code that is controlled by JavaScript.
[0046] Enforcement outside the browser: Enforcement outside the
browser can be achieved by intercepting the browser's system calls
and only allowing those calls that are according to policy. % Calls
that cannot be processed within the current instance will be
processed by creating an FBI to process them. Enforcement outside
the browser does not preclude implementing part of the enabler
mechanism inside the browser. In fact, for technical reasons that
we explain later in this section, this is the approach we take.
Compromising the enabler mechanism would not allow an attacker to
access sensitive content through the wrong browser instance.
System Components
[0047] The system has two main components. One component, an
enforcer, intercepts system calls and modifies them as needed to
ensure that sensitive content is only accessed through the
appropriate instance of the browser. Another component, an enabler
determines when sensitive content is requested and, if needed,
launches a new fresh instance of the browser to access the
content.
Enforcer
Intercepting System Calls.
[0048] To intercept system calls, the system includes a ptrace API
available in Linux. This API allows one program (tracer) to be
notified and take control of every system call made by another
program (browser). The kernel puts the browser to sleep when it
makes a system call and notifies the tracer. The tracer can then
modify the contents of process virtual memory or registers and then
let the browser resume execution. When the system call gets
executed and returns from the kernel, and before the control gets
back to the browser, the kernel notifies the tracer once more. At
this point the tracer can also modify the return value of the
system call. Using this API enables us to control every interaction
between the browser and the operating system. The ptrace API is
also used by many sandboxing applications to control system
access.
[0049] In one embodiment, the browser issues a connect system call
when it needs to make a network connection, and it uses recvfrom or
read to receive data from a network host.
Redirecting DNS Queries.
[0050] When a browser makes a DNS query, the tracer checks whether
or not the requested network name is allowed to be accessed by the
current browser instance. If it is not allowed to be accessed, the
tracer changes the IP addresses in the DNS response to a predefined
IP address which is the loopback address. This prevents the browser
from connecting to the restricted website. At the same time, the
attempted access is detected by the enabler mechanism of Auto-FBI
and a new instance is launched as needed.
Intercepting IP Communication
[0051] The IP addresses used by the browser are not always preceded
by DNS queries. In fact for security reasons, IP addresses obtained
from DNS queries are typically cached (IP pinning) by browsers even
if the TTL from the DNS response is set to 0. [0052] IP addresses
that are cached by the browser and obtained from a previous DNS
query. IP addresses that are obtained through DNS queries are
cached by Auto-FBI in a whitelist if the original DNS query is not
redirected. A later use of such an IP address is compared against
Auto-FBI's whitelist of IP addresses. If the IP address is not on
the whitelist, it is blocked. [0053] Browser hardcoded IP
addresses. Hand-coded IP addresses. IP addresses that are directly
entered by the user have legitimate usages such as setting up some
LAN services (NAT setup for example). Such usages should be
allowed. As a policy one can allow some LAN IP addresses and
associate a class with each allowed address.
[0054] FIG. 4 illustrates a scenario 400 in which a browser
instance whose COI class is different from that of the website it
is trying to connect to. First it makes a DNS query to resolve the
IP address (1), the DNS response is detected by the system (2) and
the requested domain name is checked against the list of COI
classes (3). Since the browser is running in a different class, the
system rewrites the IP address in the DNS response (4) and returns
the result to the browser. The browser would not have access to the
actual IP address for www.bank.com and hence it is not able to
connect to it. The browser could not communicate directly with
www.bank.com using the actual IP address of www.bank.com because
that IP address of www.bank.com is not added to the whitelist of
the current instance.
Enabler: Launching Fresh Instances
[0055] To manage browser instances running in the system and
launching new instances, the FBI system implements or otherwise
includes a daemon which keeps track of all browser instances. The
information on which new instances need to be launched comes from
the extension component. The extension reports all URLs requested
by the user to the daemon and also listens for incoming messages
from the daemon in which case it will open the URL in a new tab.
The daemon decide how to handle the URL sent by the extension:
either open it in an existing browser instance by sending a message
to the extension running in that instance or open a fresh instance
in case an appropriate instance is not running.
[0056] As discussed in the previous section, having part of the
enabler mechanism in the browser does not affect security. Even if
a browser is compromised and the extension is also compromised, all
that would affect is the URL communicated by the extension, but
that has no effect on the tracing of system calls and blocking
them. That part is independent and is enforced through a mechanism
that is completely outside the browser by the Enforcer. So,
compromising the browser might affect the progress requirement of
the browser, but does not affect the safety requirements of the
enforcement.
Security Guarantees
[0057] The FBI system restricts communication to IP addresses that
are on the whitelist for the COI class of the executing browser
instance. The IP addresses on the whitelist of one class can be one
of the following: (1) IP addresses corresponding to a domain from
the common domain list, or (2) IP addresses of a domain in the COI
class. So, if DNS is not compromised, only content from sources in
a given COI class can run on a browser instance associated with
that class. For sensitive content whose servers are typically
authenticated, the assumption on DNS not being compromised is not
needed and the system provides the desired isolation that ensures
that there is no leakage of sensitive content between various
instances (assuming the authentication mechanism is secure). This
means that attacks such as CSRF or Clickjacking cannot be used to
access sensitive content. In fact, content (scripts) used to launch
such attacks are assumed to belong to COI classes that are not part
of the sensitive COI classes. This is especially evident in the
novice user scenario. For the experienced user, a non-judicious
choice of classes can pose a security risk.
Implementation Details
[0058] The prototype is composed of two separate modules: (1)
Enforcer and (2) Enabler.
Enforcer
[0059] Using Linux ptrace API, the system may trace every system
call made by a child process to keep track of the application's
access to system resources including network and file system.
[0060] There are two options for a tracer to start tracing the
tracee: (1) TRACEME and (2) ATTACH. The first option is usually
used in the following way: the tracer forks a new child process and
in the child process calls ptrace with TRACEME command, which
causes it to be traceable by its parent process (the tracer), then
it runs the target program by calling exec. The second option can
be used to trace an already-running-process by attaching to it. The
enforcer uses the TRACEME option by default (including the
implementation for Firefox), but due to Chrome's use of the SETUID
access flag in its sandboxing process, the enforcer uses the ATTACH
option with GOOGLE Chrome. Using ATTACH leaves an enforcement gap:
from the time that the tracer launches Chrome until the tracer
attached to the browser, the browser is not traced. Using ATTACH
leaves an enforcement gap: from the time that tracer launches
Chrome until the tracer attaches to the browser, the browser is not
traced. This should not be a source of vulnerability if the default
home pages are safe. Using ATTACH means that part of the enforcer
that is involved in setting up the tracing is browser dependent,
but the rest of the enforcement when the ATTACH option is used and
the whole enforcement using the TRACEME option are generic and not
dependent on the browser. The ptrace API allows one to trace a
process and all its child processes and threads by specifying
certain options: PTRACE_O_TRACEFORK and PTRACE_O_TRACECLONE. So the
system can make sure that a process cannot escape the tracer by
creating a child process or a new thread.
[0061] For every system call made by the tracee, the tracer is
notified twice: once before the call is handed over to the kernel
for execution and once after the call returns from the kernel but
before it is handed back to the tracee. So the tracer has two
chances to modify a system call: it can change the parameters
provided by the tracee to the kernel, or change the values returned
by the kernel. To restrict the browser's access to websites, the
system may monitor the following system calls: itemize [0062]
Connect: Connects a socket file descriptor to a network address. It
is also used for IPC. [0063] rcvfrom: Receives data through a
socket file descriptor [0064] read: Can be used to receive data
from the network (through a socket file descriptor)
DNS Queries
[0065] To prevent the browser from accessing certain websites, the
system keeps track of the DNS queries made by the browser to find
out if it is trying to connect to a restricted website. The system
can prevent the access by rewriting the IP addresses in the DNS
response to point to a predefined address.
[0066] In order to accomplish this, the system needs to process the
following system calls: rcvfrom and read. (Depending on the
browser, other system calls such as rcvmsg and rcvmmsg may need to
be processed). If the port number matches the port number of the
DNS protocol, the system read the IO buffer from the tracee's
memory and analyzes the DNS message. If the system decide to
rewrite the IP addresses in the DNS message, the system do so by
writing to the tracee's virtual memory.
IP White-list
[0067] To prevent the browser from connecting to a restricted
website by using a hard-coded IP address, the system employs a
white-list of IP addresses that the browser is allowed to connect
to.
[0068] Initially, it is populated with the DNS service IP address
(usually the local DNS client, 127.0.0.1) and a list of pre-defined
IP addresses (to allow for LAN addresses). When the browser makes a
DNS query, one of the following happens: either the response is
changed to prevent access in case the URL is not allowed or the IP
addresses in the response are added to the white-list. When the
browser issues a connect system call, the system would only allow
it to go through if the IP address is in the white-list. By doing
this, the system ensures that the browser does not circumvent the
system mechanisms by connecting to a hard coded IP address
directly.
Enabler
Browser Extension
[0069] All browser instances are equipped with an extension that is
responsible for two tasks: (1) report all user-requested URLs to
the daemon and (2) open a new tab for URLs requested by the daemon.
When the extension reports a URL to the daemon, the daemon decides
if the URL should be handled by the reporting instance or by
another instance. The system has developed separate JavaScript
extensions for Mozilla Firefox and Google Chrome. Since the
extensions cannot directly communicate with the daemon, the system
has a native application written in C that is responsible for
forwarding messages between the daemon and the extension. The
native application communicates at one end with the browser
extension through the browser API Native Messaging API in case of
Google Chrome and in js-ctypes API in case of Mozilla Firefox) and
it communicates with the daemon on the other end through Unix
Domain Sockets. The native application's process is a child process
of the browser instance and hence can be considered a part of the
browser extension module. It is interesting to note that the code
size of the extension (and its associated native application) is
small compared to that of the enforcer: around 3K lines of code for
the enforcer and daemon vs. 460 for the chrome extension and 280
for the Firefox extension.
Daemon
[0070] The daemon is a multi-threaded C program that uses Unix
Domain Sockets to communicate with browser extensions. It is
responsible for deciding how to handle restricted URLs by either
dispatching it to an already-running instance that is allowed to
access the URL or creating a fresh new instance. For every browser
instance running in the system, it has a separate thread to
communicate with the instance. It keeps a record for each running
browser instance along with a queue of outgoing messages for that
instance in a shared data structure. When it receives a message
from a browser extension, it chooses to either send a message to
the browser extension in one of the running browser instances or
run a fresh instance. It compares the COI class of the URL
contained in the incoming message with that of the sender. If they
match, it ignores the message because the sender will not be
blocked when attempting to access the URL; otherwise it decides how
to handle the message according to the classes file.
Browser Instances and User Profiles
[0071] A browser instance is associated with a profile that
captures its execution state. In practice, most browsers support
user profiles to enable the multi-user use case. User profiles are
very similar in different browsers: a folder stored somewhere in
the user's home directory that contains information such as the
user's web history, cookies, cache, and preferences. Fortunately,
most browsers also provide a way of using multiple profiles for a
user in addition to the user's default profile. In case of Mozilla
Firefox and Google Chrome, creating a fresh instance of the browser
is as easy as creating an empty directory and instructing the
browser to use that directory to store the user profile (though
this would be cumbersome to do manually). In one embodiment, the
default user profile (the one managed by the user) is associated
with the general COI class. Other COI classes do not necessarily
have a persistent profile: a temporary profile can be created
whenever the instance is created and can be deleted after the
instance is closed. Alternatively, profiles for COI classes can be
kept when the browser is closed. The user spends most of the time
using the default profile since most URLs fall into the general COI
category, hence allowing the user to manage that profile improves
usability. Using temporary profiles for other COI classes ensures
tighter security without much effect on usability.
System Architecture
[0072] In some embodiments, any suitable hardware can be used to
provide one or more portions of the components and functions
described above, and such hardware can be implemented in one or
more general purpose devices such as a computer or a special
purpose device such as a client, a server, etc. Any of these
general or special purpose devices can include any suitable
components such as a hardware processor (which can be a
microprocessor, digital signal processor, a microcontroller, etc.),
memory, communication interfaces, display controllers, input
devices, etc., and can be configured to operate in response to
software instructions consistent with the functionality described
herein.
[0073] In some embodiments, any suitable computer readable media
can be used for storing instructions for performing the processes
described herein. For example, in some embodiments, computer
readable media can be transitory or non-transitory. For example,
non-transitory computer readable media can include media such as
magnetic media (such as hard disks, floppy disks, etc.), optical
media (such as compact discs, digital video discs, Blu-ray discs,
etc.), semiconductor media (such as flash memory, electrically
programmable read only memory (EPROM), electrically erasable
programmable read only memory (EEPROM), etc.), any suitable media
that is not fleeting or devoid of any semblance of permanence
during transmission, and/or any suitable tangible media. As another
example, transitory computer readable media can include signals on
networks, in wires, conductors, optical fibers, circuits, and any
suitable media that is fleeting and devoid of any semblance of
permanence during transmission, and/or any suitable intangible
media.
[0074] FIG. 8 illustrates an example of a computing node 800 which
may comprise an implementation of the system 201. The computing
node 800 represents one example of a suitable computing device and
is not intended to suggest any limitation as to the scope of use or
functionality of embodiments of the invention described herein.
Regardless, the computing node 800 is capable of being implemented
and/or performing any of the functionality described above.
[0075] As illustrated, the computer node 800 includes a computer
system/server 802, which is operational with numerous other general
purpose or special purpose computing system environments or
configurations. Examples of well-known computing systems,
environments, and/or configurations that may be suitable for use
with computer system/server 802 may include personal computer
systems, server computer systems, thin clients, thick clients,
handheld or laptop devices, multiprocessor systems,
microprocessor-based systems, set top boxes, programmable consumer
electronics, network PCs, minicomputer systems, mainframe computer
systems, and distributed cloud computing environments that include
any of the above systems or devices, and the like.
[0076] Computer system/server 802 may be described in the general
context of computer system executable instructions, such as program
modules, being executed by a computer system. Generally, program
modules may include routines, programs, objects, components, logic,
data structures, and so on that perform particular tasks or
implement particular abstract data types. Computer system/server
802 may be practiced in distributed cloud computing environments
where tasks are performed by remote processing devices that are
linked through a communications network. In a distributed cloud
computing environment, program modules may be located in both local
and remote computer system storage media including memory storage
devices.
[0077] As shown in FIG. 8, computer system/server 802 in computing
node 800 is shown in the form of a general-purpose computing
device. The components of computer system/server 802 may include
one or more processors or processing units 804, a system memory
806, and a bus 808 that couples various system components including
system memory 806 to processor 804.
[0078] Bus 808 represents one or more of any of several types of
bus structures, including a memory bus or memory controller, a
peripheral bus, an accelerated graphics port, and a processor or
local bus using any of a variety of bus architectures. Such
architectures may include Industry Standard Architecture (ISA) bus,
Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus,
Video Electronics Standards Association (VESA) local bus, and
Peripheral Component Interconnects (PCI) bus.
[0079] Computer system/server 802 typically includes a variety of
computer system readable media. Such media may be any available
media that is accessible by computer system/server 802, and it
includes both volatile and non-volatile media, removable and
non-removable media.
[0080] System memory 806 may include computer system readable media
in the form of volatile memory, such as random access memory (RAM)
810 and/or cache memory 812. Computer system/server 802 may further
include other removable/non-removable, volatile/non-volatile
computer system storage media. By way of example only, storage
system 813 can be provided for reading from and writing to a
non-removable, non-volatile magnetic media (not shown and typically
called a "hard drive"). Although not shown, a magnetic disk drive
for reading from and writing to a removable, non-volatile optical
disk such as a CD-ROM, DVD-ROM or other optical media can be
provided. In such instances, each can be connected to bus 808 by
one or more data media interfaces. As will be further depicted and
described below, memory 806 may include at least one program
product having a set (e.g., at least one) of program modules that
are configured to carry out the functions of embodiments of the
invention.
[0081] Program/utility 814, having a set (at least one) of program
modules 816, may be stored in memory 806, as well as an operating
system, one or more application programs, other program modules,
and program data. Each of the operating system, one or more
application programs, other program modules, and program data or
some combination thereof, may include an implementation of a
networking environment. Program modules 816 generally carry out the
functions and/or methodologies of embodiments of the invention as
described herein.
[0082] Computer system/server 802 may also communicate with one or
more external devices 818 such as a keyboard, a pointing device, a
display 820, etc.; one or more devices that enable a user to
interact with computer system/server 802; and/or any devices (e.g.,
network card, modem, etc.) that enable computer system/server 802
to communicate with one or more other computing devices. Such
communication can occur via Input/Output (I/O) interfaces 822.
Still yet, computer system/server 802 can communicate with one or
more networks such as a local area network (LAN), a general wide
area network (WAN), and/or a public network (e.g., the Internet)
via network adapter 824. As depicted, network adapter 824
communicates with the other components of computer system/server
802 via bus 808. It should be understood that although not shown,
other hardware and/or software components could be used in
conjunction with computer system/server 802. Examples, include, but
are not limited to: microcode, device drivers, redundant processing
units, and external disk drive arrays, RAID systems, tape drives,
and data archival storage systems, etc.
[0083] The embodiments of the present disclosure described herein
are implemented as logical steps in one or more computer systems.
The logical operations of the present disclosure are implemented
(1) as a sequence of processor-implemented steps executing in one
or more computer systems and (2) as interconnected machine or
circuit engines within one or more computer systems. The
implementation is a matter of choice, dependent on the performance
requirements of the computer system implementing aspects of the
present disclosure. Accordingly, the logical operations making up
the embodiments of the disclosure described herein are referred to
variously as operations, steps, objects, or engines. Furthermore,
it should be understood that logical operations may be performed in
any order, unless explicitly claimed otherwise or a specific order
is inherently necessitated by the claim language.
[0084] The foregoing merely illustrates the principles of the
disclosure. Various modifications and alterations to the described
embodiments will be apparent to those skilled in the art in view of
the teachings herein. It will thus be appreciated that those
skilled in the art will be able to devise numerous systems,
arrangements and methods which, although not explicitly shown or
described herein, embody the principles of the disclosure and are
thus within the spirit and scope of the present disclosure. From
the above description and drawings, it will be understood by those
of ordinary skill in the art that the particular embodiments shown
and described are for purposes of illustrations only and are not
intended to limit the scope of the present disclosure. References
to details of particular embodiments are not intended to limit the
scope of the disclosure.
* * * * *
References