Containment Policies

An unsuspecting user may install an extension that is either vulnerable to script injection or includes malicious code, and grant that extension permission to access one (or all) origins at installation time. In both cases, the consequence can be that an extension may read sensitive information from a page and

Figure 6.2: The Containment Policy Assignment Scheme.

disclose it to an unauthorized server. ScriptPolice allows the browser to enforce a containment policy that restricts such disclosure of pages’ sensitive data by extensions.

We implement ScriptPolice’s containment policies with Discretionary Access Control (DAC). The DAC mechanism entails making access-control decisions at sensitive data sources (pages) and network data sinks. Thus, a containment policy may prevent a script from obtaining sensitive data at the sources or restrict it from disclosing data to unauthorized origins via network sinks.

Our choice of DAC over IFC for implementation of the containment policy stems from our desire to offer a robust defense against maliciously written extensions. ScriptPolice’s IFC implementation does not propagate taint across implicit data flows [71], nor do prior IFC systems, for many implicit flows [73]. Despite an IFC-based containment policy, an extension deliberately written to disclose pages’ sensitive data could launder taint via implicit data flows and still disclose sensitive information to unauthorized origins. However, propagating taint along implicit flows causes all data written within a conditional statement’s body to become tainted, and runs the risk of tainting data that are not in fact sensitive, and thus throwing spurious exceptions when non-sensitive data leave the browser. Note that the IFC- based Prevention policy is immune to this problem by virtue of the threat model it addresses: it targets extensions that are “honest but vulnerable,” i.e., are not written to launder taint.

We define two design requirements that our containment policy must fulfill. First, the policy must achieve its goal, i.e., restrict disclosure of pages’ sensitive data by malicious and vulnerable extensions. Second, the policy must allow extensions to do their work on sensitive and non-sensitive data unless working with sensitive data contravenes the policy’s goal, e.g., if an extension requires sending sensitive data to an unauthorized server. To achieve the latter requirement, we designed three containment poli- cies, one for each of the canonical extension behaviors in Section 6.3.1: Containment Sink ACL None, Containment Sink ACL, and Containment Source.

Figure 6.2 shows the policy assignment scheme that the browser follows to choose the containment policy with which to confine an extension. An extension’s manifest file enumerates to which remote origins that extension sends pages’ data. If the manifest file contains no remote origins, the browser classifies the extension as a local one and applies the Containment Sink ACL None policy. If the manifest file specifies specific origins, the browser identifies a remote extension, and consults the user to learn

whether she approves sending sensitive information from pages to these origins. With the user’s consent, the browser enforces the Containment Sink ACL policy, automatically customized to allow releasing data only to the approved origins. Otherwise, the browser enforces the Containment Source policy. Finally, an extension may require sharing page data with origins only determined at runtime, i.e., as declared at extension installation time, with arbitrary origins. In this case, the browser classifies the extension as promiscuous and confines it with the Containment Source policy. Note that policy selection and the described automated customization take place once at an extension’s installation, and the chosen policy is enforced when the extension executes.

Containment Sink ACL None. The Containment Sink ACL None policy restricts extensions from send- ing any information to remote servers. It thus denies disclosure of sensitive information that extensions may read from pages. The restriction on network communication prevents extensions from performing remote functionality; therefore, this policy is enforced only on local extensions which do not need the network.

Containment Sink ACL. Containment Sink ACL is a generalization of the Containment Sink ACL None policy. It targets remote extensions. As shown in the policy assignment scheme in Figure 6.2, the browser enforces Containment Sink ACL if a user authorizes sharing sensitive information with the origins specified in an extension’s manifest file. The browser automatically customizes the default Con- tainment Sink ACL policy to allow information to flow to the authorized origins. Thus, the customized policy allows an extension to read sensitive and non-sensitive information from pages and send it to user-authorized remote servers. However, the policy restricts the extensions from disclosing any infor- mation to unauthorized origins. The extension may perform local and remote functionality on sensitive and non-sensitive data.

An extension may wish to include third-party content via static links, e.g., AdBlock Plus retrieves a list of ad filters from a remote server using a static URL. In this case, we require the extension to declare all static URLs for remote resources in its manifest file. When a user installs such an extension, the browser tailors the Containment Sink ACL or Containment Sink ACL None policy to allow these URLs. With the customized policy, the extension may use the declared URLs to retrieve remote resources, but it cannot disclose sensitive data by embedding such data into the URLs. We describe below how we prevent leaks by “modulating” information over requests for static URLs. Note that users need not authorize static links.

Containment Sink ACL and Containment Sink ACL None impose no restrictions on access to pages’ data, and an extension confined with one of these policies may perform its function on sensitive and non- sensitive data alike. Thus, these policies do not interfere with the functionality of local and remote extensions. The policies require no modification to pages, and only Containment Sink ACL requires user authorization of remote origins.

Both Containment Sink ACL policies allow potentially malicious code to handle sensitive data, and so risk disclosure of sensitive information via covert channels [92]. We block one important such channel: we prevent an extension from encoding page data covertly by requesting static URLs in a

“modulated” pattern. To do so, we prefetch all of an extension’s manifest-declared static URLs before the first execution of the extension’s content script for each page, and force all subsequent requests for static URLs during the extension’s execution to be served out of cache. We leave consideration of more esoteric covert channels for future work.

Containment Source. Our last policy is Containment Source. It denies an extension read access to sensitive data in a page. With the ScriptPolice interposition mechanism described in Section 6.4.1, the policy disables all operations on DOM elements containing sensitive data. Thus, a malicious extension cannot read sensitive data and disclose it to the network. The Containment Source policy is enforced on all promiscuous extensions and on remote extensions whose remote origins the user does not authorize to obtain sensitive information from pages. Because the policy denies access to sensitive data, it limits extension functionality on this class of data. For example, the Google Dictionary remote extension confined with the Containment Source policy displays definitions for words marked as non-sensitive and shows nothing for sensitive content.

The Containment Source policy must distinguish between sensitive and non-sensitive content in a page. To do so, it leverages the annotations described at the start of Section 6.3.

The Containment Source policy imposes no restrictions on an extension’s network communication; it simply denies read access to sensitive data. Unlike the Containment Sink ACL policies, Containment Source is immune to sensitive information disclosure via covert channels.