Issue: If remote debugging is disabled, but HTTPMonitor is enabled, a remote user can connect to and use the remote debug service. STR: 1) Enable debugging (not remote) on the target 2) enable HTTPMonitor extension on target 3) From another host, connect remote debugger to <target>:2929 4) enjoy your debugging session Remediation: It would be nice to restrict what's possible based on more than just whether or not a debugger protocol listener is listening. We can discuss some possible ways of doing this.

The HttpMonitor protocol implementation is just a proof of concept at this point. We are changing the way it attaches to the debugger server in bug 753401 and in my HttpMonitor fork at https://github.com/past/httpmonitor/. I definitely plan on having the HttpMonitor code honor the remote-enabled pref. Other than that I'm not sure what else we could do. Extensions will always be able to unconditionally open the debugger server, or even their own socket, if they so wish. I've been thinking about a separate UI menu/button that launches the debugger server without the debugger frontend and a DebuggerServer API that goes along with it, but I believe this complicates the HttpMonitor UX for no real benefit. Any other ideas are welcome, of course.

Proof of concept implementation or not, this is in mozilla-central a security hole that affects nightly users.

(In reply to Daniel Veditz [:dveditz] from comment #2) > Proof of concept implementation or not, this is in mozilla-central a > security hole that affects nightly users. Yes, although as discussed in IRC a user must both a) install the HTTPMonitor extension and b) enable serverMode via a pref in about:config. What I'd like to see is a discussion of how we present the 'enable remote tools' option to users (I appreciate we're not quite ready for that UI piece yet - is there a separate bug for this?) - I just want to make sure there are no potential surprises for users that wish to make use of this feature. Bug 755513 is probably also relevant to this discussion.

The patch in bug 758696 fixes this hole, by having the server code take the remote-enabled flag into consideration before opening the socket. I still plan to help Honza change HttpMonitor to the new API in bug 753401 (and figure out a better UX), but this fix should plug this hole for others as well.

Assigning to :past so security bugs have owners, but we expect bug 758696 to fix this.

(In reply to Daniel Veditz [:dveditz] from comment #5) > Assigning to :past so security bugs have owners, but we expect bug 758696 to > fix this. bug 758696 has landed - is this resolved now?

mgoodwin: is your initial concern addressed now?

I've tested the normal remote debugging route (which I am satisfied is OK) but I've not completed testing the netmonitor listener yet (I've had problems getting netmonitor to work as intended in the latest nightly). I'll continue with this tomorrow morning (hopefully it'll all be sorted before California wakes up).

I'm unable to test this in a conventional sense as the fix for bug 758696 broke the HTTPMonitor server code. That said, it's apparent that it's no-longer possible to start a RemoteDebugger server without knowledge of the fact you're supposed to be explicit in allowing the connection. This is because the old style DebuggerServer.init(), will fail as invocations of an undefined _allowConnection can't succeed.

Also making the status flags match, given bug 758696 is resolved in 15.

Given comment 9, I'm not sure if and how QA can verify this fix; please advise.

I don't think it makes much sense for QA to verify this, either. HTTPMonitor is not released yet, and if one were to build its current version from source, it wouldn't work at all (a pull request to properly fix HTTPMonitor is already submitted). Also note that no release version of Firefox has contained this bug, since the debugger is enabled in 15, where the fix for bug 758696 landed.

Thank you, Panos. Marking this bug [qa-].

I assume that this is Firefox only and Thunderbird and Seamonkey would not be affected by this bug?

(In reply to Al Billings [:abillings] from comment #14) > I assume that this is Firefox only and Thunderbird and Seamonkey would not > be affected by this bug? HttpMonitor's install.rdf has the SeaMonkey targetAPplication ID, so if SeaMonkey ships the remote debugger server, it may be affected, in theory. Honza would know more than I do. In practice, since no Firefox (and presumably SeaMonkey) release has ever contained this bug, and since HttpMonitor hasn't reached release status yet, I believe end users are not affected.

(In reply to Panos Astithas [:past] from comment #15) > In practice, since no Firefox (and presumably SeaMonkey) release has ever > contained this bug, and since HttpMonitor hasn't reached release status yet, > I believe end users are not affected. Well, unless they installed the non-released version of the extension, which is available to the public.