1053725 - local (file://) link whitelisting should apply to subdomains

Status: RESOLVED FIXED

(Core :: Security: CAPS, defect)

Description

[Björn Kautler]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

We want file:// links to work on all intranet systems without configuring each individual system that maybe gets added in the future.
The systems are e. g.
- http://wiki.company.com
- https://jira.company.com
- https://confluence.company.com
- ...

To achieve this we have a group policy that sets the following preferences:

capability.policy.policynames = localfilelinks
capability.policy.localfilelinks.checkloaduri.enabled = allAccess
capability.policy.localfilelinks.sites = company.com



Actual results:


This used to work fine in prior versions.
Now the links are dead again unless the systems are configured explicitly which is very inconvenient.

I guess the cause is the same that caused Bug #995943 and in #995943 it was only fixed for fully specified pages.


Expected results:

I'd like to be able to specify a pattern of sites genericly again, either how it was before with

capability.policy.localfilelinks.sites = company.com

or if this is too insecure for some reason, at least with some patterning mechanism like

capability.policy.localfilelinks.sites = http://*.company.com, https://*.company.com

Comment 1

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]: Things are broken

Bobby?

Comment 2

[Benjamin Kerensa [:bkerensa]]

(In reply to Boris Zbarsky [:bz] from comment #1)
> [Tracking Requested - why for this release]: Things are broken
> 
> Bobby?

Comment 3

[Lawrence Mandel [:lmandel] (use needinfo)]

Marking 32 as won't fix as it's too late in the cycle to take any potential fix. This is still tracking 33, so a fix on Aurora is appreciated.

Comment 4

[Bobby Holley (:bholley)]

bz - see the discussion in bug 1028321 and let me know what you think we should do.

Comment 5

[Boris Zbarsky [:bzbarsky]]

How much pain would it be to use the etld service to make foo.jira.com allowed if jira.com is allowed?  We'd need something a bit more complicated than a single hashtable lookup but not _that_ much more, I'd think.

Comment 6

[Bobby Holley (:bholley)]

Attachment: When one domain is whitelisted for file:// URI access, whitelist all subdomains. v1

Comment 8

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/654b0c2a0913

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/654b0c2a0913

Comment 10

[Bobby Holley (:bholley)]

Comment on attachment 8486099 [details] [diff] [review]
When one domain is whitelisted for file:// URI access, whitelist all subdomains. v1

Flagging for ESR approval for similar reasons to bug 1061136.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: When transitioning to ESR31, enterprise administrators will no longer have a way to whitelist a group of subdomains together. The process of enumerating all of their subdomains explicitly in the file may be tedious or impossible. 
Fix Landed on Version: 35
Risk to taking this patch (and alternatives if risky): Low risk. 
String or UUID changes made by this patch: None.

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Bobby, is it also possible to have the uplift request for aurora & beta? Thanks

Comment 12

[Bobby Holley (:bholley)]

Comment on attachment 8486099 [details] [diff] [review]
When one domain is whitelisted for file:// URI access, whitelist all subdomains. v1

See comment 11.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6703d9aa4a0a
https://hg.mozilla.org/releases/mozilla-beta/rev/a91c79c7e64e
https://hg.mozilla.org/releases/mozilla-esr31/rev/5116585a16b7