B2G App Security Model/Threat Model

Scope of this Document

The goal of this document is to capture the threats that the B2G Web App platform may face.

  Note: Please feel free to add to this document but please keep discussion to the discussion page, or the B2G mailing list.

The current proposal for B2G is that all "apps", will be Open Web Apps, and this document seeks to list and discuss the threats which this model will need to address. At a high level, this model is:

• All apps are websites, that are marked as trusted by the user through an install process
• Installing will request permissions for an App, based on a trusted app store model
• These permissions will allow the web page to access device functionality

The key risks considered in this document are:

• What scenarios might result in the compromise of sensitive phone functions?
• How might untrusted code end up being trusted?
• How might benign code be changed to be malicious?

Threats Summary

In order to discuss the permissions model for B2G, we need to discuss the threats posed. By default Web Apps are untrusted, not unlike any other web page, and therefore the permissions available to them are limited. The goal is to mitigate the threats faced by Web Apps to a level where they can be trusted to perform sensitive functions. Note that this should be a considered an initial draft as use cases and system design of B2G is still under discussion.

The threats considered include:

• Network Compromise
• Vulnerable Web App
• App Host Compromise
• App Store Compromise
• Platform Vulnerabilities
• Malicious Web App
• UI Spoofing

These controls for these threats fall into two basic categories:

• Restricting the distribution of sensitive permissions
• Increasing the control over the integrity and authenticity of a Web App code

Ultimately the B2G model will need to be flexible enough to account for all possible Web Apps, from the most critical of phone functions to those Web Apps which require no additional permissions at all. Overly strict controls for apps which do not require permissions stifles development and adoption, but not providing controls for critical functions will destroy confidence in the platform.

Threats

Network Compromise

Web Apps hosted remotely face network threats upon every launch (note that even cached offline apps have their manifest checked upon each launch). Web Apps may (and are expected to) send information back to remote servers or load additional scripts and resources, although this may not be necessary (or appropriate) for critical system Web Apps.

Potential Countermeasures

• TLS/SSL
• HTTP Strict Transport Security(HSTS)
• Static Web Apps with use explicit update process (i.e. static HTML/JS/CSS web app, loaded explicitly in a package, more similar to the extension model)
• Enforce a Content Security Policy (CSP) policy on critical Web Apps
  • Prevent loading of remote scripts for critical apps
  • Prevent loading of remote content altogether
• Code Signing for static applications

Vulnerable Web App

Web application layer vulnerabilities are very common occurrences and should be expected in Web Apps. The consequence for most web applications issues will be the same as for website i.e. compromise will mainly impact the organization running the app, e.g. fraud from an internet banking Web App. But in addition, for a B2G app with permissions, any attack with the ability to inject JavaScript into application code will have the ability to perform actions on the phone with the permissions of the application.

Potential Countermeasures

• Static HTML/JS: Restrict dangerous permissions to static HTML applications - easier to review, less likely to suffer web application flaws).
  • Dynamic HTML/JS: virtually no permissions at all.
  • eval etc. severely restricted (different security context)
  • Static apps could also be signed; where as dynamic web applications cannot (note signing does not mitigate the vulnerable Web App case really, it is more a control over the compromised server case, see below)
  • Explicit update process: Introduce explicit updates of static Web Apps (so a compromised server does not directly translate to compromise phone – a device is only compromised the next time it is updated, by which time the issue may be addressed).
  • Enforce a CSP policy on static Web Apps (having static code is no benefit, if vulnerable code is just loaded at runtime)
    • Prevent loading of remote scripts for critical apps
    • Prevent loading of remote content altogether
• Segregating critical B2G permissions, and limiting distribution of these to a subset of applications
  • Security of web application and server could be under direct control of the store (e.g. a Telco which hosts its own apps)
  • Contractual controls with third parties

App Host Compromise

Similar to the vulnerable web application case – the question is asked whether a compromised server hosting a Web App would allow the attacker to execute actions on the phone with the permission of the compromised Web App.

Potential Countermeasures

• Controls are largely the same as for vulnerable web applications - see above.
• Code Signing is an effective control here (assuming that dynamic code loading and running - e.g. eval or script injection - is not permitted). Signing with a key not stored on the hosting server so that compromise of the server doesn’t directly result compromised phones.

App Store Compromise

Similar to the app host scenario – this section asks the question of whether a compromised server hosting the app store could leverage the trust relationship with a user to trick them into installing malicious apps. If attackers have already compromised another web app, could they also update the trust settings for the app to elevate its privileges? If the store is hosting privileged apps with special powers (phone dialer, etc) could they expose users or carriers to direct financial losses.

Potential Countermeasures

• Controls are largely the same as for vulnerable web applications - see above.
• Code Signing is an effective control here (assuming that dynamic code loading and running - e.g. eval or script injection - is not permitted). Signing with a key not stored on the hosting server so that compromise of the server doesn’t directly result compromised phones.

Platform Vulnerabilities

Vulnerabilities in the B2G platform might allow a range of security issues:

• Same-origin bypass or other privilege escalation bug, allowing an application to access data or functionality it shouldn’t have access to
• A memory corruption vulnerability that gives control of content process
• Attacks against other processes (media server, rild etc)?

Potential Countermeasures

• Effective security update process
• Unique application identifiers? (i.e. spoofing an domain is not enough to gain access to another application’s permissions)
• Sandboxing low-privileged content processes
• Reduce attack vectors to vulnerable code
  • Prevent loading of remote scripts for critical apps
  • Prevent loading of remote content
  • I.e. enforce a CSP policy on critical Web Apps

Malicious Web App

A user installs an application that turns to be malicious. The are many different ways this could occur:

• A benign application could change to be malicious, or load a malicious script
• An untrustworthy store might be trusted by the user
• The user might be tricked into installing an application

Potential Countermeasures

• Process for removing permissions from known bad Web Apps (maybe even blocking them, or adding them to phishing and malware protection list)
• Trusted stores pre-installed on the B2G device, and contracts with third-party developers
• Appropriate warnings and acknowledgements when adding new trusted stores
• Trust delegation model where store can trust other stores to grant only certain permissions (i.e. maintain direct control over critical permissions)
• Trusted UI for installing application
• Requirement for HSTS for Apps granted permissions (Strict SSL even?)
• User can audit permission usage of an app so s/he can uninstall the app if it seems to be doing something undesirable
• eval and script injection (appending text as a script node to the body of the page) need to be restricted operations
  • or executed in a different security context that is given highly-restricted permissions.

UI Spoofing

A malicious website or Web App can imitate the look and feel of another Web App in an identical manner (i.e. this threat is higher than on a platform that has native apps, since Web App behavior could be identical between apps), or it could simulate native OS dialogs to steal sensitive information.

The attacks that are possible here are varied, complex and constantly changing as new security controls are introduced. Some attacks might be:

• An website spoofing another to phish the user for credentials or other sensitive information (e.g. spoof wifi settings dialog to phish wifi credentials?)
• Spoof another application in order to be sold instead of legitimate application (close the malicious application case above)
• Spoof device lock code or email password prompt

Potential Countermeasures

• Most countermeasures to malicious web app case, also apply here
• Web Apps must be installed to gain permissions (ie websites on the same domain as a web app will not get the same permissions)
• Trusted UI
• Applications which are granted the right to operate full-screen should be severely limited, and an easily-recogniseable surround (frame) presented around apps at all times.
  • Video is the only real major exception but must be banned from being interactive in full-screen mode, as it could potentially be used as an attack vector (playback of still images - paused using HTML5 - representing phishing attack dialog boxes etc).

Privacy-invasive but non-malicious app

An application wants information about the user that the user is not comfortable sharing with the app. The application is not outright malicious; it follows FTC guidelines (e.g., it has a privacy policy). However, the user might not like what the app will do with his/her data. Some examples might be:

• An app tags posts with your current location
• An app turns the camera on for an optional chatting feature
• An app collects contact lists for marketing purposes

Potential Countermeasures

• Several of the countermeasures for the malicious web app case also apply here
• Contracts between web sites/apps and the stores that distribute them