914543 - SecReview: New Remote Firefox OS debugger features

Status: RESOLVED FIXED

(mozilla.org :: Security Assurance, task)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

New remote debugger features are landing to allow much requested support of remote debugging, inspection and other features on Firefox OS. This review is to understand the security implications or making this change, and potential mitigating controls for any threats identified.

Comment 1

[Alexandre Poirot [:ochameau]]

I can see various tweaks to mitigate priviledges escalation, but I think it goes beyond what we are going to expose via app debugging. Today, when you toggle the remote debugging setting, you enable adb and devtool remote protocol. It isn't very clear how much you can get from just having access to adb shell/push/pull. But it is clear that, you can gain additional priviledges via the webapps install feature, that exists since 1.0.1. You can install hosted and packaged apps with web or priviledged permissions. You can also install certified app, but only on non official builds.

We can limit app debugging to only a subset of apps. Like blacklisting certified, or only allow debugging apps you installed via devtools. We can also keep buildtime pref to hide features.
But builtime pref basically disallow most people to get access to these features.
Hacking firefox phones should be easy in order to bring contributors onboard. For example, gaia is 100% made of HTML/JS/CSS. So it should be trivial to customize you phone deeply. We are currently trying to build a firefox addon that would allow executing all gaia buildsteps easily without any command line/software dependency other than firefox desktop. We should then make it easy to push custom gaia to the phone and also easily enable devtools to debug gaia. Requiring build time prefs often means having to build a custom gecko/gaia and flash it. That's all but easy and should be only required for people hacking on gecko or gonk.

Do you have any other idea in mind other than filtering which apps you can debug?

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

So after discussing this here, I see the following high level options:

1. Do nothing. Take the approach that user's who want to protect their data should set a passcode. We can maybe reduce the negative security impacts through mitigation such as:
- remote wipe feature
- support setting a pin code on the debugger (but how to encourage a regular user to do this?) 

2. Have some hurdle which requires wiping user profile before enabling remote debugging service the first time. 

Pros: protects user data from casual access
Cons: introduces a DoS scenario (anyone can quickly and easily wipe your phone).

3. Somehow make user data non-accessible while remote-debugging is enabled???
- duplicate profiles? 
- Not sure if this is possible or even desirable

At the moment option 1 seems like the only acceptable solution here, but I want to give broader visibility to this discussion.

Comment 3

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Should have also mentioned the mitigation of limiting which apps debugger can connect to as a potential mitigation for option 1, but I take your point about privileged apps being just as likely to have sensitive data.

Comment 4

[Paul Theriault [:pauljt] (no longer reading bugmail)]

So then maybe the answer is to have different settings for different phones:

Production devices: remote debugger will not connect to privileged or certified apps

Developer devices: remote debugger will connect to any app

There is then the question of how can a developer user convert their phone from a production phone to a developer phone, but maybe that is a separate question.

Comment 5

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Actually one slightly better refinement:

Production devices: remote debugger will not connect to *signed* privileged or certified apps. You can still connect to privileged apps you sideload via the simulator.

Developer devices: remote debugger will connect to any app

Comment 6

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Even better, and what I sent to the dev-b2g list for comment: 

For production devices, you should only be allowed to debug the apps you are developing. That is, the remote debugger will only connect to web apps and privileged apps pushed to the device via the simulator. It will _not_ connect to certified apps, or signed privileged apps installed from the store. The only exception to this i can think of is we probably support remote debugging of tabs within the browser app (and possibly bookmarked web pages opened by the system app).

For developer builds, the remote debugger would connect to any app.

Comment 7

[Jim Blandy :jimb]

I don't think limiting the apps that the debugger can connect to really fits well with our goal to have the phone be a hackable, open device.

It would make sense to me to require the user to set a passcode before enabling debugging. The settings dialog could simply bring up the passcode-setting dialog box, with a note saying, "You must set a passcode on your phone to enable debugging."

Comment 8

[Dave Hylands [:dhylands]]

(In reply to Jim Blandy :jimb from comment #7)
> I don't think limiting the apps that the debugger can connect to really fits
> well with our goal to have the phone be a hackable, open device.
> 
> It would make sense to me to require the user to set a passcode before
> enabling debugging. The settings dialog could simply bring up the
> passcode-setting dialog box, with a note saying, "You must set a passcode on
> your phone to enable debugging."

I don't think that helps. If you lose your phone which has no passcode set, then the finder of the phone only needs to set a passcode and then they can enable remote debugging, which isn't really any different from just allowing remote debugging to be enabled when its unlocked.

Comment 9

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Paul Rouget proposed a way to do option 2 above, in his words:

2 "remote debugging" checkboxes.

- remote debug (give access to the apps you're working on)
- system remote debug (give access to everything)

'System remote debug' would wipe your /data/ partition first (only the
first time it's enabled).

We have a factory reset button anyways, so there is no increased DoS risk.

That sounds good to me. We just need to figure out what 'wipe' actually means. As noted in a later email on dev-b2g, we probably just want to delete sensitive user data, not apps themselves. Maybe this code can help with the implementation of this: http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#3048

3048   _clearPrivateData: function(appId, browserOnly, msg) {
3049     let subject = {
3050       appId: appId,
3051       browserOnly: browserOnly,
3052       QueryInterface: XPCOMUtils.generateQI([Ci.mozIApplicationClearPrivateDataParams])
3053     };
3054     this._notifyCategoryAndObservers(subject, "webapps-clear-data", null, msg);
3055   }

Comment 10

[Jim Blandy :jimb]

(In reply to Paul Theriault [:pauljt] from comment #9)
> Paul Rouget proposed a way to do option 2 above, in his words:
> 
> 2 "remote debugging" checkboxes.
> 
> - remote debug (give access to the apps you're working on)
> - system remote debug (give access to everything)
> 
> 'System remote debug' would wipe your /data/ partition first (only the
> first time it's enabled).

... and require you to set a passcode, right?

Comment 11

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Jim Blandy :jimb from comment #10)
> (In reply to Paul Theriault [:pauljt] from comment #9)
> > Paul Rouget proposed a way to do option 2 above, in his words:
> > 
> > 2 "remote debugging" checkboxes.
> > 
> > - remote debug (give access to the apps you're working on)
> > - system remote debug (give access to everything)
> > 
> > 'System remote debug' would wipe your /data/ partition first (only the
> > first time it's enabled).
> 
> ... and require you to set a passcode, right?

Do you mean setting a passcode and enable checking this passcode at the lockscreen? i.e. do you mean, when you enable system debugging we force you to have a passcode set to secure your developer device? Might be good to encourage developers to use a passcode, but I would want to allow them to turn of lockscreen checking if they want.

Or maybe you mean a passcode for the system debugging feature?

Comment 12

[Jim Blandy :jimb]

(In reply to Paul Theriault [:pauljt] from comment #11)
> > > 'System remote debug' would wipe your /data/ partition first (only the
> > > first time it's enabled).
> > 
> > ... and require you to set a passcode, right?
> 
> Do you mean setting a passcode and enable checking this passcode at the
> lockscreen? i.e. do you mean, when you enable system debugging we force you
> to have a passcode set to secure your developer device? Might be good to
> encourage developers to use a passcode, but I would want to allow them to
> turn of lockscreen checking if they want.
> 
> Or maybe you mean a passcode for the system debugging feature?

Having thought about it a bit more, I'm not sure my original suggestion matters.

If the phone has a general passcode set, then debugging certainly should not go around that. And eventually there will be pairing codes for debugging securely over Wifi. But beyond those, I don't think there need to be more passcodes involved.

Comment 13

[Paul Theriault [:pauljt] (no longer reading bugmail)]

No further review on this topic.