1013379 - Automatically allow remote debugger connections for Browser Toolbox

Status: NEW

(DevTools :: Debugger, enhancement, P5)

Description

[Mike Hoye [:mhoye]]

Remote debugger should have an off-by-default option to auto-allow connections from localhost. 

This is one of a series of papercut bugs around gecko development highlighted by Marcos recently; the allow/refuse dialog hid itself behind another window, when it should have just worked.

Comment 1

[Girish Sharma [:Optimizer]]

Setting devtools.debugger.prompt-connection to false will not bring up the prompt. Is that what is required ?

Comment 2

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Girish Sharma [:Optimizer] from comment #1)
> Setting devtools.debugger.prompt-connection to false will not bring up the
> prompt. Is that what is required ?

As long as you leave "devtools.debugger.force-local" set to true (which is the default) so that the server only listens on loopback, you should be able to safely disable the prompt as Optimizer suggested.

Comment 3

[Mike Hoye [:mhoye]]

Fantastic! That's exactly what we need, we just need to surface it in the devtools.

With that in mind, I think we need a checkbox under Toolbox -> Toolbox Options -> Advanced Settings -> Enable remote debugging  that says [] Automatically allow connections from localhost.

Comment 4

[Mike Hoye [:mhoye]]

We could also use a Bugzilla feature that says "You used the word 'just' in a bug report. Is that really what you meant?"

Comment 5

[Girish Sharma [:Optimizer]]

(In reply to Mike Hoye [:mhoye] from comment #4)
> We could also use a Bugzilla feature that says "You used the word 'just' in
> a bug report. Is that really what you meant?"

sorry ?

Comment 6

[Mike Hoye [:mhoye]]

(A little joke, sorry. I'm trying to break the habit of using the word 'just' when I'm talking about other people's work, particularly when I don't know how much work it would really entail.)

Comment 7

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Mike, is the use case we're discussing here when using the Browser Toolbox to debug desktop Firefox?  Or some other version of remote debugging (b2g, Fennec, etc.)?

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

We already do this for Thunderbird actually. I think its a good idea, although there might be security implications on a shared machine where any user can connect to localhost.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

If the security team agrees, then I'm all for it. And to be clear, this is just for debugging desktop Firefox.

Another solution with a different risk-usability tradeoff would be to always clear the option on shutdown or startup. It would also be a worse state to be in for those who are currently flipping the pref.

Comment 10

[Benjamin Smedberg]

If this is the browser toolbox, is there a reason we can't require a shared secret (passed in the environment when we start the debugger) for the connection?

Comment 11

[Panos Astithas (he/him) [:past] (please ni?)]

We could do something like that, but it would introduce extra complexity to the debugger server for a use case that only affects a small percentage of users (and has a good workaround, too). A similar idea that we haven't found the time to implement yet, is to use a domain socket for the browser toolbox, like we do in Firefox OS (and possibly soon Fennec - bug 916777), which would entirely eliminate the risk.

Comment 12

[Mike Hoye [:mhoye]]

(In reply to J. Ryan Stinnett [:jryans] (on PTO May 23 - June 4) from comment #7)
> Mike, is the use case we're discussing here when using the Browser Toolbox
> to debug desktop Firefox? 

That specifically, yes.

(In reply to Panos Astithas [:past] from comment #9)
> 
> Another solution with a different risk-usability tradeoff would be to always
> clear the option on shutdown or startup. 

Two other prefs in the Advanced section already do this, "disable cache" and "disable js", so perhaps I should file another bug to have that whole section of options reset on restart.

Admittedly I don't know how often Firefox is deployed to multiuser systems, but I suspect that number is very small.

Comment 13

[Mark Goodwin [:mgoodwin]]

(In reply to Panos Astithas [:past] from comment #9)
> If the security team agrees, then I'm all for it. And to be clear, this is
> just for debugging desktop Firefox.

I can see why this is useful.

This would be problematic in (at least) 3 scenarios:
1) Other users are logged in to the system (as mentioned above, this may be rare - also, securing a machine where an adversary has physical access is difficult for other reasons)
2) malicious software on the machine (likely game over anyway)
3) Local webservers serving java / flash / other things that allow slightly-more-relaxed-than-same-origin TCP.
4) vulnerabilities in the debug protocol that allow forged HTTP requests to compromise the browser (hopefully very unlikely since the debugger server is quite aggressive in throwing unexpected stuff away).

These are probably unlikely enough enough that we wouldn't need to loose sleep over them.  That said, I'd still rather users don't enable this unless they need to so I'd like for us to warn the user that this could result in mischief.  I'll have a think about what sort of a warning we could provide (leaving the needinfo to remind myself to do this).

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #10)
> If this is the browser toolbox, is there a reason we can't require a shared
> secret (passed in the environment when we start the debugger) for the
> connection?

This would be nice. Nicer still would be a solution that worked in other scenarios too (desktop to fennec and desktop to fxos)

Comment 14

[Benjamin Smedberg]

Maybe we need to clarify the bug. This bug should be about the Firefox desktop Browser Toolbox and making it "just work" without a prompt, securely. We *can* do that without compromising security either by using a shared secret, and maybe with sockets.

If somebody were going to volunteer a patch, what approach would be accepted?

Comment 15

[Panos Astithas (he/him) [:past] (please ni?)]

I would be OK with either approach, but I think the socket one would be simpler to implement.

Comment 16

[Mark Goodwin [:mgoodwin]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #14)
> Maybe we need to clarify the bug. This bug should be about the Firefox
> desktop Browser Toolbox and making it "just work" without a prompt,
> securely. We *can* do that without compromising security either by using a
> shared secret, and maybe with sockets.
> 
> If somebody were going to volunteer a patch, what approach would be accepted?

I'd be happiest with some kind of shared secret. I'd assume there would be an issue with complicated setup here - but that's just a guess?

Comment 17

[Mark Goodwin [:mgoodwin]]

(In reply to Mark Goodwin [:mgoodwin] from comment #13)
> I'll have a think about what sort of a warning we could provide
 
Something along the lines of "Enabling this option could allow other programs or users on this computer to take control of Firefox. Are you sure you want to do this? (OK / No thanks)" should be fine.

Comment 18

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

We do have a secure RDP auth scheme now that we use with Wi-Fi debugging for Firefox OS / Fennec devices.  It creates self-signed certs on both ends to identify client and server.  Verification that the client is trusted relies on scanning a QR code on first connection though, which is quite impractical when connecting on the same machine.

In any case, I believe some of that auth machinery could be reused, but using a different strategy to verify that the client is who they claim to be.

Comment 19

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

From older comments, this is only about Browser Toolbox, not the general case of anything that might want to connect on localhost (other things could be automation tools, etc.)

Comment 20

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

One variation that is simpler for the user would be to do something like:

1. When opening a Browser Toolbox, some kind of one time use token is created by the server and passed to the client via the initial chrome URL to load in "--chrome" command line arg (it would be appended to the URL as a query param).
2. Client passes this to the server over RDP when authenticating the connection
3. Server accepts if it gets the expected token

Mark, does that seems "good enough" to not require prompts for the Browser Toolbox case?  The only flaw I can think of is some malware on the system could watch for the command line arg of the new process and connect to the server first, consuming the one time use token for its own purposes.

If that's deemed not safe enough, then I think a strategy like we use on mobile devices would make sense:

1. Browser Toolbox opens in a new process
2. Server process displays a prompt for a token
3. Browser Toolbox shows a token to give to the server
4. User copies token into the prompt on the server, and has the option of "allow and remember" to automatically allow all future connections (since both sides are identified by certs which we check during auth).

Comment 21

[Mark Goodwin [:mgoodwin]]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #20)
> Mark, does that seems "good enough" to not require prompts for the Browser
> Toolbox case?

I think so.

Comment 22

[Bryan Clark (DevTools PM) [:clarkbw]]

Until this bug is fixed I filed bug 1375280 for flipping the pref in Nightly only.