B2G Threats/Controls

[ptheriault]

Chris,

Below is a summary of threats and controls for further discussion. Disclaimer: this is my understanding from various conversations, wiki pages, bugs and IRC chats, so it's rough, probably varies from whats implemented (or what the final goals are), but its a starting point. Ultimately the aim is a considered security model with security controls commensurate to the threats posed, but to start with I want to start a discussion regarding what threats have been considered so far in the project, and the current thoughts around what controls are in place or planned. I know that a lot of the things below have already been considered in the project prior to me coming on board so the main aim for me is to run through the state of things, and start capturing the B2G security model.

Firstly I wanted to document some assumptions:

- All B2G applications will be Web Apps - there is no such thing as native applications. Some web apps may be treated differently though based on security characteristics (e.g. Came shipped with the phone, loaded from trusted location, local access only, served over SSL only etc)
- B2G will ship with a number of included Web Apps (Gaia) to handle all the tasks of running the device. These could potentially be replaced by the user with alternatives
- Web APIs will provide access to Web Apps so they can perform their desired role. E.g. An app acting as a Dialer will need access to the Web Telephony API, in order to to make telephone calls
- Access to sensitive APIs will be controlled by permissions

Threats Summary
=============
In order to discuss the security measures built into B2G, we need to discuss the threats posed.The following is a high level list of threats for further discussion:

- Platform Vulnerabilities
- Exploit gives control of content process
- Attack against other processes (media server, rild etc)?
- Malicious Web App
- User tricked installing malicious application
- Legitimate app is compromised at the network layer
- Compromised web app server for Web Apps hosted remotely
- Vulnerable Web App
- Web application security threats (XSS, SQLi, etc)
- Framework weaknesses (same-origin bypass, privilege escalation, abuse communication between apps?)
- Lost device
- User data compromised

Controls Summary
=============
In response to the above threats, what controls to we want to consider? The following controls have come up in various discussions. There are probably other controls to be discussed/raised/captured as well.

- Low-privileged processes and process sandboxing
- Web Apps will run in low-privileged process? How is this implemented?
- Segregation between less trusted and more trusted Web App
- What about other processes (media server, rild, etc)
- Hardening of the underlying OS
- I've not seen any mention of this, but it has come up in security discussions.
- Segregation between Web Apps
- Separate by domain, other restrictions?
- Restriction for Apps trusted with sensitive permissions
- local-only sandbox, network-only sandbox etc
- restrict cross-domain communication etc
- load only over SSL
- load only from trusted developer
- load once, then cache. Drop permissions if app changes (or prevent from changing without update workflow)
- Restricting permissions and protection against privilege escalation
- Security restrictions for special Web App cases
- browser app (<iframe browser>, other cases?)
- permissions manager
- others?
- Data Protection
- Encryption
- Login

Discussion is 5pm (PST) tomorrow (7th) using same phone conference as b2g meeting.

Cheers,

Paul

[Adam Barth]

I won't be able to make the call, but I've left one comment inline:

On Tue, Mar 6, 2012 at 10:15 PM, ptheriault <pther...@mozilla.com> wrote:
> Chris,
>
> Below is a summary of threats and controls for further discussion. Disclaimer: this is my understanding from various conversations, wiki pages, bugs and IRC chats, so it's rough, probably varies from whats implemented (or what the final goals are), but its a starting point. Ultimately the aim is a considered security model with security controls commensurate to the threats posed, but to start with I want to start a discussion regarding what threats have been considered so far in the project, and the current thoughts around what controls are in place or planned. I know that a lot of the things below have already been considered in the project prior to me coming on board so the main aim for me is to run through the state of things, and start capturing the B2G security model.
>
> Firstly I wanted to document some assumptions:
>
> - All B2G applications will be Web Apps - there is no such thing as native applications. Some web apps may be treated differently though based on security characteristics (e.g. Came shipped with the phone, loaded from trusted location, local access only, served over SSL only etc)
> - B2G will ship with a number of included Web Apps (Gaia) to handle all the tasks of running the device. These could potentially be replaced by the user with alternatives
> - Web APIs will provide access to Web Apps so they can perform their desired role. E.g. An app acting as a Dialer will need access to the Web Telephony API, in order to to make telephone calls
> - Access to sensitive APIs will be controlled by permissions
>
> Threats Summary
> =============
> In order to discuss the security measures built into B2G, we need to discuss the threats posed.The following is a high level list of threats for further discussion:
>
> - Platform Vulnerabilities
>        - Exploit gives control of content process
>        - Attack against other processes (media server, rild etc)?
> - Malicious Web App
>        - User tricked installing malicious application
>        - Legitimate app is compromised at the network layer
>        - Compromised web app server for Web Apps hosted remotely
> - Vulnerable Web App
>        - Web application security threats (XSS, SQLi, etc)

^^^ One way to address this threat is to require that B2G apps have a
Content-Security-Policy that meets some minimum bar. Chrome has
started doing this with its extensions and packaged apps (see
<http://blog.chromium.org/2012/02/more-secure-extensions-by-default.html>).
You might want to do something similar.

Adam

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security

[Jean-Marc Desperrier]

ptheriault a écrit :

> - restrict cross-domain communication etc

This is hardly sufficient to offer a significant protection from a
malicious application. If the application wants to break the protection
brought by cross-domain restriction, it will.
Cross-domain restriction has a use case, but it's not that big.

> - load once, then cache. Drop permissions if app changes (or prevent
> from changing without update workflow)

If you successfully find a model that's safe by default, it's not
obvious whether this is still is an important feature.
If it's safe by default, we don't care what the application actually
contains, it will still be safe.

The model that gives permissions based on the exact content of the
extension is weak. Very weak. The user didn't audit the extension, he
saw how it behaves, and thought it was correct. But he didn't see
everything. If the application is dangerous after the change, it may
just as well have already been before.
So you really need to make it safe by default, and not rely on having to
blindly trust what the application contains, and "drop permission if the
app changes" is a bit snake oil.

However in some implementations of the safe by default model, it may be
required to associate an identity with the app, so that it doesn't
successively acquire permissions that combined together are dangerous,
so that you are able to reject a permission for an app that used to have
another incompatible one.

The "CRX Package Format" that chrome uses
(http://code.google.com/chrome/extensions/crx.html) includes a digital
signature. That's not PKI, there's no authority that validates that
signature, it just proves the origin of the extension stays the same.
If the signature of the extension changes, it's not really a problem,
but it just makes it a separate extension, that has no access to the
data (or maybe already obtained permissions) of the previous one.

[Chris Jones]

----- Original Message -----
> From: "Adam Barth" <abarth-...@adambarth.com>
> To: "ptheriault" <pther...@mozilla.com>
> Cc: dev-se...@lists.mozilla.org, "Mozilla B2G mailing list" <dev...@lists.mozilla.org>, cjo...@mozilla.com
> Sent: Tuesday, March 6, 2012 10:30:48 PM
> Subject: Re: [b2g] B2G Threats/Controls
>
> I won't be able to make the call, but I've left one comment inline:
>
> On Tue, Mar 6, 2012 at 10:15 PM, ptheriault <pther...@mozilla.com>
> wrote:
> > Chris,
> >

> > - Vulnerable Web App
> >        - Web application security threats (XSS, SQLi, etc)
>
> ^^^ One way to address this threat is to require that B2G apps have a
> Content-Security-Policy that meets some minimum bar. Chrome has
> started doing this with its extensions and packaged apps (see
> <http://blog.chromium.org/2012/02/more-secure-extensions-by-default.html>).
> You might want to do something similar.
>

Yes, definitely. Thanks for the link.

Cheers,
Chris