Group Policies for Firefox can bypass Tor Browser's proxy settings
Assuming your Windows environment has a Firefox group policy (GPO) that specifies e.g. using system proxy settings then Tor Browser happily follows that and is ignoring its own proxy settings without notifying users.
What should actually happen is that Tor Browser is ignoring those Firefox GPO settings instead.
This got tested with Tor Browser 8.0.8 on Win10 1709.
Thanks to Kit Chung for this report.
Activity
Replying to tom:
Hm. I haven't found this code yet. This is referring to the Windows Group Policy mechanism, and not the Firefox policy mechanism, right?
Good question: I'd say, yes, but I am not sure as I don't know much about group policies. The report says "If a GPO policy tells Firefox to use system proxy setting" and says, that a specific key is written to the registry which seems to cause Tor Browser to ignore its own proxy settings.
I think we should wire up both to be ignored when MOZ_PROXY_BYPASS_PROTECTION is enabled
Agreed.
I think this is talking specifically about the Firefox Enterprise Policy report we recently enabled in #29445 (moved)
-
As far as I can tell, the only way to bypass the proxy settings is by putting a policies.json file containing the relevant setting inside Tor Browser's data directory (on desktop) or the package directory (on mobile).
Can the original poster confirm/clarify that is what they did?
Perhaps we want to prevent this out of an abundance of caution; but if you can do this you can generally bypass lots of Tor Browser security mechanisms.
-
I did find another way to control this besides the policy file. I believe that we should revert #29445 (moved), set browser.policies.testing.disallowEnterprise to true, not support enteprise policies in any way shape or form, and test a release and alpha build to ensure the proxy can't be bypassed.
-
Replying to tom:
I did find another way to control this besides the policy file. I believe that we should revert #29445 (moved), set browser.policies.testing.disallowEnterprise to true, not support enteprise policies in any way shape or form, and test a release and alpha build to ensure the proxy can't be bypassed.
Hm, so
browser.policies.testing.disallowEnterpriseset totruealone does not solve our problems here? Or is it just too risky relying just on that pref alone? Because if folks know what they are doing and want to have policy support why not allowing that feature? If the pref alone is not enough that sounds like a bug with the pref handling which should get fixed independently of this ticket.Trac:
Status: new to needs_information
Keywords: N/A deleted, tbb-8.5-must-alpha added -
No, the pref should be enough. I was suggesting revert the other one to carry one less customization.
Policy support will be screwy though. As this issue illustrates, if you enable policy support, you will pick up a policy for Firefox, if it's present in certain locations, rather than a Tor Browser-specific policy. If we wanted to support policies we probably should require them to be TB-specific.
-
Replying to tom:
No, the pref should be enough. I was suggesting revert the other one to carry one less customization.
Policy support will be screwy though. As this issue illustrates, if you enable policy support, you will pick up a policy for Firefox, if it's present in certain locations, rather than a Tor Browser-specific policy. If we wanted to support policies we probably should require them to be TB-specific.
Fair enough. I've pushed
bug_29916(https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_29916) to make the changes you suggested and have them up for review. However, I am still not convinced that this is the whole picture. In particular, I feel those changes do not explain how the registry-based bypass is working, given that the pref is only checked at one place andareEnterpriseOnlyPoliciesAllowed()results infalsefor the stable series, yet the bug report was made against 8.0.x.Trac:
Status: needs_information to needs_review
Keywords: TorBrowserTeam201904 deleted, TorBrowserTeam201904R added -
Replying to gk:
However, I am still not convinced that this is the whole picture. In particular, I feel those changes do not explain how the registry-based bypass is working, given that the pref is only checked at one place and
areEnterpriseOnlyPoliciesAllowed()results infalsefor the stable series, yet the bug report was made against 8.0.x.I also can't explain this, and agree. But the patch looks good to me.
-
Replying to tom:
Replying to gk:
However, I am still not convinced that this is the whole picture. In particular, I feel those changes do not explain how the registry-based bypass is working, given that the pref is only checked at one place and
areEnterpriseOnlyPoliciesAllowed()results infalsefor the stable series, yet the bug report was made against 8.0.x.I also can't explain this, and agree. But the patch looks good to me.
Thanks. Pushed to
tor-browser-60.6.1esr-8.5-1(commit e95c515352094f6c3d943a3313628c370feb18f2 and 6e730d5184f8d74860488f8fa998bd1e0023281f) to get the changes in our next nightly build. Setting toneeds_informationto figure out a way to repro the original bug report. I'll try to ask the reporter for steps to reproduce and whether they can still reproduce the problem with the fixes (whcih we have so far) committed.Trac:
Keywords: tbb-8.5-must-alpha, TorBrowserTeam201904R deleted, TorBrowserTeam201904, tbb-8.5 added
Status: needs_review to needs_information -
Let's track the remaining things in #30575 (moved).
Trac:
Status: needs_information to closed
Resolution: N/A to fixed mentioned in issue #30575 (moved)
mentioned in issue #31978 (moved)
mentioned in issue #32418 (moved)
