Security/Reviews/Debugger

Item Reviewed

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

• Since the last secreview meeting to look at the debugger, a basic debugger server and UI have landed in mozilla-central. Currently the debugger UI is available, by default, in the Tools -> Web Developer menu but remote debugging must be enabled via a preference prior to first use.
• These features aim to provide a user interface and a remote interface for debugging

- What solutions/approaches were considered other than the proposed solution? - Why was this solution chosen? - Any security threats already considered in the design and why?

What solutions/approaches were considered other than the proposed solution?

`

Why was this solution chosen?

`

Any security threats already considered in the design and why?

`

Threat Brainstorming

• Protocol considerations:
  • I feel we should talk about this- do we want to block on this bug, or are we comfortable that a sufficiently strongly worded warning is enough?
• UI Considerations
• Chrome enables remote debugging by starting the browser with a command line option. no encryption of the channel in anyway. Opera does the same. Initiate connection from the mobile browser - so this may help with security concerns. When you open yourself up for inspection, you are aware (aside from attacks on the local network - do you know you're connecting to the right debugger).
• Action item from last secreview: [dchan] think about how to secure the channel and how to connect to it - possibly worth taking a look at other remote debuggers e.g. gdbserver, Visual Studio, other browsers {BY: before we open any ports}
• Initiating from mobile device (debuggee) harder, so would like to initiate through the desktop.
• Debugger -> Debuggee. Flaws in protocol could be an issue. Need to get consent from user.
• Debugging is pref'ed off by default.
• Use cases: 1) ? , 2) desktop->b2g, 3) Debugging desktop->desktop.
  • Maybe we could limit the number of ips we listen to.
• When mobile device turns on debugging it is on forever. Not per session, and no reminder. User may not remember to turn it off. Notification on connection should be required. <-- this implies that we don't think 'convenience' features like "don't bug me about this again" are a good idea
• the b2g question is an interesting one. In this case, debugging could have big implications for the permissions model.
• We can do the notifications for each new connection to the debuggee with the address of the debugger. The address of the debugger should show up on the debugger as well, so the user can tell if they match. We can do this for now, until we add encryption in a later release.
• Do we want to differentiate wifi and localhost/over usb?
• What has the debugger connected to? A single window, or any window. b2g their is only one window/DOM. On Desktop - you initiate it from a window, and connects to the selected window (not all windows/tabs). In the future will have a UI for selecting the tab you want to debug.
• debuggee listening on port 6000
• We could have the listen address as a pref.
• Different scripts on debugger and debuggee (user agent detection for mobile devices) - https://bugzilla.mozilla.org/show_bug.cgi?id=755661. Debuggee requesting help - debugger loads script which ends up being malicious json packets.
• Provide pref to limit connections to localhost only (for situations where people who forget to turn debugging off). This is the case for desktop->desktop, but probably won't be in the desktop->mobile cases. What should the default be? localhost or wifi
  • 2 prefs - allow debugging via localhost / allow debugging via anywhere. Both disabled by default.
  • Original intention was to have one pref for lots of things - enable remote debugging tools.
  • Chrome debugging will be an option you can turn on in the future.
  • If we can trick someone into changing a pref, its a serious issue everywhere, not just here. Depends on the pref - the name of the pref, what it does, etc.
• Attacks on debugger from displayed content. Is it just text?
• Debugger is scriptable; user interface doesn't have that baked in. An addon or something can do that.

Action Items