Security/Reviews/Firefox/RemoteDebug
From MozillaWiki
Date: 2011.10.17
- Items to be reviewed
- protocol spec: https://wiki.mozilla.org/Remote_Debugging_Protocol
- feature page: https://wiki.mozilla.org/DevTools/Features/Debugger
- Client API: https://wiki.mozilla.org/Debugger_Client_API
- How the automation team uses the TCP conection: http://hg.mozilla.org/users/mdas_mozilla.com/marionette-pq/file/a970218205df/marionette-extension#l20
Contents
Introduce Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- JSDBG1 around since 1999
- JSDBG 2 shipped a few releases ago
- remote debugging is meant to expose this on a streaming protocol & a UI
- standard type of debugger
- features
- Protocol implementation (preffed on) for FX 11
- UI (preffed off)
transports
- in process (nsIPipe) - used by UI
- remote over TCP - there's an API in a JSM - not exposed to content - you would need an add on or something like that to enable it - down the road this may change and there will need to be a way to turn it on (eg to integrate to eclipse) - this may not be a TCP port at this point any more
- the debugger can execute JS - right now it can't debug chrome but this is a goal, so it may run with full privileges
What solutions/approaches were considered other than the proposed solution?
- considered Chromes protocol
- we had other/more needs this did not meet so we went our own direction
- possible blog post coming on why Chrome's protocol wasn't suitable
- we had other/more needs this did not meet so we went our own direction
Why was this solution chosen?
- ^^ see above
- remote protocol was essential for the mobile device use case
Any security threats already considered in the design and why?=
- Know we need to deal with ports
- know we may need to deal with securing the channel
Threat Brainstorming
- authentication / authorization ?
- eventually this will open up a listening port
- Ensure that this can't happen by accident
- should channel be encrypted ? sniffing possibly sensitive data and possibly command injection - depends on the use case, should warn/document users
- protocol implementation / fuzzing ? (the protocol is JSON and the feature is implemented in JS)
- If you have the ability to connect (feature is enabled), then exploiting it is no longer required.
Conclusions / Action Items
- [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}