Closed Bug 1042166 Opened 10 years ago Closed 10 years ago

Disabling checkloaduri doesn't work

Categories

(Core :: Security: CAPS, defect)

Product:
Core
Component:
Security: CAPS
Version:
31 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: romain.failliot, Unassigned)

References

Details

(Keywords: steps-wanted) 

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:

1. Go to about:config and disable checkloaduri
2. Go to an "http://" page that make "file://" links to a distant Windows machine (e.g. "file://///localdomain/BuildSystem/output.txt")

I'm not the owner of the intranet of my firm, but if there is a solution for that, they might consider using Firefox in the end.
Also, the URI is really "file://///". I don't know if it's normal. The idea is to make a link to a distant Windows machine, in Explorer it would give this URI: \\localdomain\BuildSystem\output.txt.


Actual results:

Nothing


Expected results:

Load the "file://" page
(In reply to romain.failliot from comment #0)
> 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:
> 
> 1. Go to about:config and disable checkloaduri
> 2. Go to an "http://" page that make "file://" links to a distant Windows
> machine (e.g. "file://///localdomain/BuildSystem/output.txt")

links like <a href="file://///localdomain/...">Link</a> ? Probably not. But what *do* you mean? Can you provide a testcase?

I suspect we don't want to fix this, because it'd introduce a gaping security hole, but...
Flags: needinfo?(romain.failliot)
Something like this (in your html):
<html><body>
  <a href="file://///your-machine-name/output.txt">local link</a>
</body></html>

Then run this on an web server and try to click the link. Of course, the file must exist on your machine. So if you type "\\your-machine-name\output.txt" in your Windows Explorer, it will open the file.

Here, it just does nothing, not even a visual feedback showing that it doesn't work. So you keep on clicking until you guess that the link might be a local link that doesn't work even if you disabled checkloaduri.

Interesting facts:
- The link works when using the "locallink" extension: https://addons.mozilla.org/fr/firefox/addon/locallink/, but you have several clicks to do to open the local link, it's not very straight forward.
- The link works on IE and on Chromium.

I understand the security reasons behind all this, but my firm will never change their ways just because of Firefox, especially if it already works on all the other browsers (I've struggled enough years to let it go now :( ).

That said, "checkloaduri" is a property that says "I know you put this for my own security, but I know what I'm doing and I want to by pass it", but it actually doesn't really work: I expect to have the same behavior as in IE and Chromium when I disable this property.

Moreover, I'm pretty sure that if my firm reacts like that toward Firefox, it's definitely not the only one. I did have answers from the IT saying that "Firefox devs just doesn't want to work in firms". I'm completely against this assertion, but I don't make the rules here.

I know it's a security breach, but it's a breach that all the other browsers have. The good point for Firefox is that it's off by default. But when we activate it, it should work as expected, even if it's a big breach in the security...
Flags: needinfo?(romain.failliot)
Bad phrasing (English is not my mother tong). What the IT told me is that:
"Firefox devs just doesn't want *Firefox* to work in firms".
AFAICT this was fixed in bug 995943. Can you provide more details about what exact prefs you're setting and what you're seeing not working?
Blocks: 995943
Component: Untriaged → Security: CAPS
Flags: needinfo?(romain.failliot)
Keywords: steps-wanted
Product: Firefox → Core
I'm using the 31 branch (just re-checked ;)).

For the test, I've created a brand new profile, changed the proxy settings so that it works at my company and disabled the "checkloaduri" property in about:config.
Then I got to our project's build system website and click on one of the local links => nothing happened (I really mean *nothing*: no error page, no pop-up, no blinking, no stalling, nothing...).

I tried to copy the link and paste it in a new tab. This way I can see the text file.
Flags: needinfo?(romain.failliot)
(In reply to romain.failliot from comment #5)
> I'm using the 31 branch (just re-checked ;)).
> 
> For the test, I've created a brand new profile, changed the proxy settings
> so that it works at my company and disabled the "checkloaduri" property in
> about:config.

This was what my question was about: what prefs are you setting? security.checkloaduri ? Have you tried looking at bug 995943 for what prefs to toggle?
Flags: needinfo?(romain.failliot)
But in the release notes (https://www.mozilla.org/en-US/firefox/31.0/releasenotes/), I've seen this:
> Removal of the CAPS infrastructure for specifying
> site-specific permissions (via capability.policy.*
> preferences). Most notably, attempts to use this
> functionality to grant access to the clipboard will no
> longer work. The sole exception is the checkloaduri
> permission, which may still be used as before to allow
> sites to load file:// URIs.

Doesn't that mean that checkloaduri is the only way to disable the security system for local links?
Flags: needinfo?(romain.failliot)
I'm not sure what you're asking, but it's hard to make progress here until you answer Gijs' question about what exact preferences you're setting to what values.
Flags: needinfo?(romain.failliot)
I'm sorry, I did intend to answer Gijs' question but maybe I wasn't clear enough :/

I started a brand new profile, changed the proxy, got to "about:config" and set the "security.checkloaduri" to "false". That's the only changes that I've done.
Flags: needinfo?(romain.failliot)
(In reply to romain.failliot from comment #9)
> I'm sorry, I did intend to answer Gijs' question but maybe I wasn't clear
> enough :/
> 
> I started a brand new profile, changed the proxy, got to "about:config" and
> set the "security.checkloaduri" to "false".

That's the wrong pref - I don't think it's even hooked up to anything anymore (we should remove it).

You need to set up a policy:

'capability.policy.policynames' = 'somepolicy'
'capability.policy.somepolicy.checkloaduri.enabled' = 'allaccess'
'capability.policy.somepolicy.sites' = 'http://example.com'
Just tried your settings and it works.

Is there a way to spread this setting across all the machines without asking each user to create a user.js file in their profile directory?

And what does the change in the release notes means?
From what I understand, it says that capability.policy.* properties have been removed and checkloaduri is the only setting left. Or did I misunderstood?
(In reply to romain.failliot from comment #11)
> Just tried your settings and it works.

Great! Going to mark this WFM then. :-)

> Is there a way to spread this setting across all the machines without asking
> each user to create a user.js file in their profile directory?

You can ship a custom installer which sets and/or locks prefs in the default profile, or you could create an add-on that does something like this, or... well, there are several options. See also e.g. https://addons.mozilla.org/en-US/firefox/addon/cck/ 

If you have more issues with this, there are relevant mailing lists which are better places to ask then this bugtracker, like https://mail.mozilla.org/listinfo/enterprise .

> And what does the change in the release notes means?
> From what I understand, it says that capability.policy.* properties have
> been removed and checkloaduri is the only setting left. Or did I
> misunderstood?

It means that using the capability.policy.* prefs will only work for checkloaduri, and you can no longer use them for clipboard access or whatever else they may have controlled in the past.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
(In reply to Bobby Holley (:bholley) from comment #10)
> (In reply to romain.failliot from comment #9)
> > I'm sorry, I did intend to answer Gijs' question but maybe I wasn't clear
> > enough :/
> > 
> > I started a brand new profile, changed the proxy, got to "about:config" and
> > set the "security.checkloaduri" to "false".
> 
> That's the wrong pref - I don't think it's even hooked up to anything
> anymore (we should remove it).

I noticed this earlier, too, but wasn't sure. I filed bug 1042975.
I thought it was a bug because I misunderstood the release notes ;)

I'm pretty sure I won't have time to do my own installer so I'll check with the CCK extension.
I'll also probably send a mail to the enterprise mailing list.

Thanks for your time!
You need to log in before you can comment on or make changes to this bug.