Closed Bug 372193 Opened 17 years ago Closed 9 years ago

disallow enablePrivilege dialog from file: URLs by default

Categories

(Core :: Security, enhancement)

Product:
Core
Component:
Security
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: myk, Unassigned)

Details

Attachments

(1 file)

testcase
459 bytes, text/html
Details 
Remote http: URLs can't request elevated privileges unless they are signed (or the user has set the signed.applets.codebase_principal_support preference to true), but local file: URLs can request privilege elevation even if they aren't signed.

Considering the user behavior around the saving of HTML documents which has prompted bug 230606, it seems like we should tighten this policy like we're planning to tighten that one and prevent local file: URLs from requesting privilege elevation unless they too are signed.
Attached file testcase — 
Here's a testcase that demonstrates the problem.  Download it to your computer and then open it via File > Open File....  It will present an "Internet Security" dialog asking you if you want to allow it to "Run or install software on your machine."
And so there is already a warning dialog, the user is already warned, why force it to be signed?  It is my machine, I should be able to do what I want with it.  I don't even see why there has to be a warning dialog.

If I choose to be totally insecure, and let viruses run rampant through my file system, and modify my files, and then I choose to load those files into my browser, I get what I deserve.

If I'm running with a secure filesystem, and proper permissions, and anti-malware software, then I can reasonably trust the content of my filesystem, and I shouldn't have to click 45 times to get things to work.  The new Vista experience, clicking 45 things to get things to work [Continue, continue, continue...] is clearly out of control.

That said, I understand most people don't think things through far enough to make intelligent, informed decisions in all cases.

Hence, it makes sense to define a pref that defines from what directory trees things should be considered secure, so that each web application can have one, and then bypass the dialog baloney.
Most users are not going to realize that downloading a document from the web and opening it from their desktop is going to expose them to security issues.
Precisely why they should go through the learning process of setting the pref suggested above.  The documentation for the pref should explain that it is not safe to do so, in all cases.  Hence, if they save a Web page from the web in their secure tree, they are choosing to trust it.  If they save it elsewhere, they are choosing not to trust it, and it is restricted in ability.

Actually, the pref would be appropriate not just for file: URLs, but also any protocol://server/prefix/  allowing unsigned pages on particular servers to be trusted also.
Err.. I'm not sure what you are arguing for.

Current situation is this:
If a user downloads a webpage and opens it from a file url that page can request UniversalXPConnect. The user does not have to set a pref for this to work. All the user needs to do is answer yes in the displayed dialog.

Suggested situation:
If the user downloads a webpage and opens it from a file url and the page requests UniversalXPConnect it will be denied. If however the user sets a pref the user will be asked when UniversalXPConnect is requested.


In other words; The problem is right now that they *don't* need to set the pref for the dialog to appear.
Most users will not set the pref, this is good since they are unlikely to understand what the dialog means anyway.
(In reply to comment #2)
> And so there is already a warning dialog, the user is already warned, why 
> force it to be signed?

Because the warning dialog doesn't do a good job of protecting users against unsafe content.


>  It is my machine, I should be able to do what I want with it.
>  I don't even see why there has to be a warning dialog.

I agree, and if what you want to do is permit all local file: URLs to have elevated privileges, even after this bug is fixed, then just set the signed.applets.codebase_principal_support preference to true, load a local app that requests such privileges (f.e. the testcase for this bug), check the "Remember this decision" checkbox in the Internet Security dialog, and then click the "Allow" button.

From then on, all local apps you load in your browser will have the elevated privilege you granted to that one app, and you won't be prompted again.


> If I choose to be totally insecure, and let viruses run rampant through my 
> file system, and modify my files, and then I choose to load those files into
> my browser, I get what I deserve.

Perhaps, if you do so intentionally and with full knowledge of the consequences, but most people don't have such knowledge or intentions, and they don't deserve the consequences.  Firefox users shouldn't have to be security experts in order to be safe on the Internet.


> If I'm running with a secure filesystem, and proper permissions, and
> anti-malware software, then I can reasonably trust the content of my
> filesystem, and I shouldn't have to click 45 times to get things to work.

Unfortunately, for the reasons pointed out in bug 230606, there are a number of common use cases in which users cannot reasonably trust the content of their filesystem.


> The new Vista experience, clicking 45 things to get things to work [Continue,
> continue, continue...] is clearly out of control.

I agree, and this bug does not propose adding more dialogs.  In fact, a side effect of fixing this bug is that Firefox will show users fewer dialogs.


> That said, I understand most people don't think things through far enough to
> make intelligent, informed decisions in all cases.

Right.  And even when they could and try to do so, they often don't have the information they would need to make those decisions well.  The Internet Security dialog in question certainly doesn't give them that information.


> Hence, it makes sense to define a pref that defines from what directory trees
> things should be considered secure, so that each web application can have one,
> and then bypass the dialog baloney.

There is already a pref like that for access to content capabilities (see http://www.mozilla.org/projects/security/components/ConfigPolicy.html), and extending this to chrome capabilities is an interesting idea that we should consider as part of the general process of figuring out good mechanisms for distinguishing between safe and unsafe applications.

But that's a separate issue from the very specific one raised in this bug report, which is that the file: scheme is unsufficient to determine that an application is safe and thus should not be used to make that determination.

(In reply to comment #6)
> 
> > If I'm running with a secure filesystem, and proper permissions, and
> > anti-malware software, then I can reasonably trust the content of my
> > filesystem, and I shouldn't have to click 45 times to get things to work.
> 
> Unfortunately, for the reasons pointed out in bug 230606, there are a number of
> common use cases in which users cannot reasonably trust the content of their
> filesystem.


I couldn't find a clear exposition of these reasons.  It would be helpful to describe them clearly and fully somewhere where they could be referenced... the reasons may be in the bug (I had read it earlier, and found it full of claims and counterclaims, none of which were very well described).




> 
> 
> > The new Vista experience, clicking 45 things to get things to work [Continue,
> > continue, continue...] is clearly out of control.
> 
> I agree, and this bug does not propose adding more dialogs.  In fact, a side
> effect of fixing this bug is that Firefox will show users fewer dialogs.


Fewer dialogs with fewer capabilities doesn't help.  Fewer dialogs and more capabilities helps.  This bug is not proposing a better solution, just a more restrictive implementation.


> > That said, I understand most people don't think things through far enough to
> > make intelligent, informed decisions in all cases.
> 
> Right.  And even when they could and try to do so, they often don't have the
> information they would need to make those decisions well.  The Internet
> Security dialog in question certainly doesn't give them that information.


Is it the job of the dialog to present all the information?  Or is it the job of the dialog to alert the user that extra-ordinary privilege is being requested, at which point the user can decide to gather the information or simply to trust the script.  The user already made the decision that the script was interesting enough to place it on the local filesystem, and theoretically knows from where it was obtained.  And if the user trusts that site, then the user will probably trust the saved script.  And if the user distrusts the site, then when the script asks for extra-ordinary privilege, via the dialog, then the answer is clear.  But "remember this" should only apply to that script, of course, not all scripts on the local filesystem.



> > Hence, it makes sense to define a pref that defines from what directory trees
> > things should be considered secure, so that each web application can have one,
> > and then bypass the dialog baloney.
> 
> There is already a pref like that for access to content capabilities (see
> http://www.mozilla.org/projects/security/components/ConfigPolicy.html), and
> extending this to chrome capabilities is an interesting idea that we should
> consider as part of the general process of figuring out good mechanisms for
> distinguishing between safe and unsafe applications.


I'm not sure what you mean about "extending this to chrome capabilities" (I think I know what those words mean, and if so, would be an interesting idea, I would agree), but if I understand what chrome is (just learning about that recently), then local web pages are a different beast (although both are on the local file system).

The referenced prefs have no clear syntax for use with file: URIs (they explicitly prohibit use of path names, which would be key for use with file: URIs) as far as I can tell, and there are certainly no examples of such usage.  It does look like they are perhaps an answer for my earlier comment about "such a pref could be used for sites as well"... and they could be an interesting template for a similar set of prefs for the local filesystem.

The referenced prefs seem to lack the ability prompt the user, though... seems like "noAccess", "sameOrigin", and "allAccess" could usefully be extended with "warnUser" which would create the sort of dialog this bug talks about eliminating... I can conceive of cases where you basically want to trust the scripts, but you have expectations about what they should need to be able to access to do their job, and would like to be warned if they attempt to exceed those access rights.

> But that's a separate issue from the very specific one raised in this bug
> report, which is that the file: scheme is unsufficient to determine that an
> application is safe and thus should not be used to make that determination.

The file: scheme is insufficient, I agree.  The dialog is less than fully informative, but is better than nothing.  This bug still seems to me to be suggesting removing something that, while not perfect, can be used effectively by an intelligent user, without replacing it with an at least equally capable and friendly alternative.  If you can't trust your filesystem, then you can't trust signed scripts either... or your Mozilla program.
It has been proven time and again that users do not read dialogs. So simply putting an alert in the users face that they are about to do something dangerous is not going to help. Many users are simply going to press OK without understanding what it means. So having the dialog is not better than simply denying the request.

For expert users such as yourself we have a pref that you can set so that you do get that dialog. The theory is that if you are savvy enough that you will set that pref you are savvy enough that you'll understand that dialog.

The suggestion in this bug is simply to honor that pref for file-uris just as we do for http-uris.

I think the enablePrivilege dialog should be subject to the same restrictions as extension installation, which currently means an out-of-the-way but visible whitelist mechanism.  Trusting "signed" scripts enough to pose enablePrivilege dialogs (regardless of who signed it), while simultaneously making it difficult to install extensions from www.squarefree.com and very difficult to grant privileges to local files, is silly.
(In reply to comment #8)
> It has been proven time and again that users do not read dialogs. So simply
> putting an alert in the users face that they are about to do something
> dangerous is not going to help. Many users are simply going to press OK without
> understanding what it means. So having the dialog is not better than simply
> denying the request.


Yep.  And Vista is going to give them lots of practice at that :)  So I guess that means that Vista's approach to security has been proven time and time again that it won't help.  But that is off-topic, sorry.  Or is it?

Anyway, the dialog is a CYA scheme, even if many users just click past it.  And that is clearly the Vista model...

 
> For expert users such as yourself we have a pref that you can set so that you
> do get that dialog. The theory is that if you are savvy enough that you will
> set that pref you are savvy enough that you'll understand that dialog.


I do feel that I am savvy enough to understand the dialog.  However, without the dialog to indicate that something is amiss--if it just fails silently-- then I'm more apt to think that saving a local copy of it doesn't save enough to let it work... or if it was delivered in some other way, that it just doesn't work.

So instead of presenting the dialog, you are making the javascript coder use a try block, and present a dialog explaining the need to set the pref to get the other dialog back...  Such is _not_ friendlier, it makes existing scripts that depend on the existing dialog break.

Presenting a one-option dialog, that alerts the user that it is failing is also annoying... but at least then when it doesn't work, and they try again, they could be given a clue by the dialog of where to look to find out how to allow it to work.  No dialog at all, and silently failing, seems extremely poor... hard for the user to understand, hard for the developer to debug.  How does it help anyone?


> The suggestion in this bug is simply to honor that pref for file-uris just as
> we do for http-uris.


If the suggestion in this bug is as you say, then it clearly implied a lot of things rather than stating them explicitly.


It doesn't fail silently, there will be an exception thrown from the request call that you can catch runtime, and if you don't there will be a message in the error console.

I agree with Jesse for what it's worth. We need to seriously revamp this UI. Though this bug is already getting too spammy for useful discussion.

Glenn: again, this bug is just about making file behave like http already does. If you think that the way http behaves is bad, please complain elsewhere. But before you do, please test what happens and see how things work. You are clearly expression opinions on things that you don't know what they do. (sorry to be rude, but this bug has become more or less impossible to follow because of this)
(In reply to comment #11)
> It doesn't fail silently, there will be an exception thrown from the request
> call that you can catch runtime, and if you don't there will be a message in
> the error console.


So how many users look at the error console?  The same ones that click past the  warning dialogs?  I think not.  For the bulk of the users, it will be a silent failure.  I did, in fact, understand about the exception before I commented... read the paragraph in comment #10 that starts "So instead of..."


> I agree with Jesse for what it's worth. We need to seriously revamp this UI.
> Though this bug is already getting too spammy for useful discussion.
> 
> Glenn: again, this bug is just about making file behave like http already does.


But http has the content privilege stuff... which doesn't work for file:, so that is not quite true.


> If you think that the way http behaves is bad, please complain elsewhere. But
> before you do, please test what happens and see how things work. You are
> clearly expression opinions on things that you don't know what they do. (sorry
> to be rude, but this bug has become more or less impossible to follow because
> of this)


Hey, I know I'm not the expert here on Mozilla architecture or the security model specifically... but I do have 25 years experience in programming large scale database systems... so I'm not completely stupid about issues of architecture or security.  But I'm trying to learn enough to write a Firefox based application.  I find some techniques that work, and the next thing that happens is Myk files a bug to take one of them away.  I see nothing in this bug that considers the big picture -- replace with something better.

I read about the security model, and play with it a little... and then when commenting, get information about other stuff that is hidden away.  Is there a comprehensive overview of _all_ the security features anywhere?  Or does one have to simply be treated rudely because the documentation is incomplete?  I'm sure if I knew all this stuff already, I could google the right search terms and find the documentation or discussions about it.  But when the documentation leads you to believe it is complete (you've followed all the links), and isn't, it is a bit hard to learn enough to comment intelligently... so, one comments non-intelligently, and gets bashed... and learns more... suggest a better technique, please.

On the other hand, it is very often the case that someone that doesn't know the whole picture, can find problems that people that do know the whole picture can't see.

OK, so I'll shut up for a couple weeks, and watch what happens, if anything.


(In reply to comment #7)
> (In reply to comment #6)
> > Unfortunately, for the reasons pointed out in bug 230606, there are 
> > a number of common use cases in which users cannot reasonably trust
> > the content of their filesystem.
> 
> I couldn't find a clear exposition of these reasons.  It would be helpful to
> describe them clearly and fully somewhere where they could be referenced.

bug 230606, comment 0 and bug 230606, comment 26 list four examples.


> Fewer dialogs with fewer capabilities doesn't help.

That depends on whom you want to help.  Fewer dialogs with fewer capabilities does help users who run scripts that shouldn't have those capabilities.

And that's what this bug proposes: to present fewer dialogs with fewer capabilities to users for whom those dialogs represent a security risk, while continuing to present the same number of dialogs with the same capabilities to users who understand those dialogs.


> This bug is not proposing a better solution, just a more restrictive
> implementation.

That's correct: this bug does not address (nor does it intend to address) the more general question of how to improve the mechanisms by which Firefox protects users from malicious web apps while granting them access to beneficent ones.

This bug only proposes one specific thing: that we plug a hole that malevolent script can use to exploit user systems.


> Is it the job of the dialog to present all the information?  Or is it the job
> of the dialog to alert the user that extra-ordinary privilege is being
> requested, at which point the user can decide to gather the information or
> simply to trust the script.

The job of the dialog is to request approval of a privilege escalation request from advanced users who understand the stakes.


> The user already made the decision that the script
> was interesting enough to place it on the local filesystem, and theoretically
> knows from where it was obtained.  And if the user trusts that site, then the
> user will probably trust the saved script.

That's true only for advanced users.


> I'm not sure what you mean about "extending this to chrome capabilities"

I mean using those preferences (or ones like them) to give web apps access to XPConnect and other parts of Firefox's chrome that aren't normally accessible to web content.


> This bug still seems to me to be suggesting removing something that,
> while not perfect, can be used effectively by an intelligent user, without
> replacing it with an at least equally capable and friendly alternative.

To the contrary, this bug proposes removing the dialog for regular users while not removing it for advanced users.


(In reply to comment #9)
> So I guess that means that Vista's approach to security has been proven time
> and time again that it won't help.  But that is off-topic, sorry.  Or is it?

Yes, it is.


> So instead of presenting the dialog, you are making the javascript coder use a
> try block, and present a dialog explaining the need to set the pref to get the
> other dialog back...  Such is _not_ friendlier, it makes existing scripts that
> depend on the existing dialog break.

It may not be friendler to web apps that have to notify advanced users to set a pref, but it's much friendler to the much larger set of regular users who are protected from exploits thereby.


> Presenting a one-option dialog, that alerts the user that it is failing is 
> also annoying... but at least then when it doesn't work, and they try again,
> they could be given a clue by the dialog of where to look to find out how
> to allow it to work.  No dialog at all, and silently failing, seems extremely
> poor... hard for the user to understand, hard for the developer to debug.
> How does it help anyone?

As Jonas noted, it doesn't fail silently, and you misunderstand what this bug proposes.  The bug proposes that we treat file: the way we treat http:.  If the way we treat http: is problematic, because it's hard for users to understand, hard for developers to debug, or for any other reason, then that's a different bug.


> If the suggestion in this bug is as you say, then it clearly implied a lot of
> things rather than stating them explicitly.

I think the description is pretty explicit, but perhaps only for folks familiar with Firefox's security architecture.


(In reply to comment #9)
> I think the enablePrivilege dialog should be subject to the same restrictions
> as extension installation, which currently means an out-of-the-way but
> visible whitelist mechanism.

That may well be true (although I'm leery of equating the two, as I suspect users understand the implications of installing extensions more than they understand what it means to grant privileges to web sites), but if so, it's a different bug (unless you're proposing that we do this only for file: URLs).

> For the bulk of the users, it will be a silent failure.

More accurately, for the bulk of users it will correctly be a silent failure of malicious code to exploit their systems, while for most of the rest it will correctly be a non-silent failure by benevolent code that explains how to make it succeed.


> > Glenn: again, this bug is just about making file behave like http already
> > does.
> 
> But http has the content privilege stuff... which doesn't work for file:, so
> that is not quite true.

But this bug is not about the content privilege stuff.  What Jonas says is exactly true for the subject of this bug.


> I see nothing in this bug that considers the big picture -- replace with
> something better.

That's true on purpose.  As I've stated repeatedly, this bug is not about the big picture.  If you want to discuss the big picture, I would encourage you to do so, since the big picture clearly needs discussion.

But that discussion should take place elsewhere.  This bug is the wrong forum for it.


> Is there a comprehensive overview of _all_ the security features anywhere?

I don't know, but the functionality being discussed is documented on this page:

http://www.mozilla.org/projects/security/components/signed-scripts.html

I think for this bug we should just do the same for file as we do for http.
That is something we can fix on branches right away.

But as a separate item we should revamp this whole thing. This may or may not
be possible to do on branch, probably not. But it's something we can do for
Gecko 1.9.
What hole would this change fix?  If a site can get a malicious script into a file:/// location and get a user to load it, it can do the same with a signed malicious script.

IMO, we should not make this change on branches.  It would break things in a confusing way and it would not improve security.
Summary: disallow misc privilege elevation requests from file: URLs → disallow enablePrivilege dialog from file: URLs by default
(In reply to comment #16)
> What hole would this change fix?  If a site can get a malicious script into a
> file:/// location and get a user to load it, it can do the same with a signed
> malicious script.

The hole created by the ability for sites to do this using unsigned script, an easier prospect.

(In reply to comment #16)
> If a site can get a malicious script into a file:/// location and get a user
> to load it, it can do the same with a signed malicious script.

Probably not, since a signed page has to be in a jar archive. Maybe if combined with an exploit that both lets the attacker put an arbitrary file in a known location *and* can specify a file: url from web content this would work, but I'll argue that bit is the real vulnerability (e.g. bug 369390, MFSA 2007-05).

There are lots of normal ways users legitimately open a local HTML file (saved page or mail attachment for example) that are not going to work for an archive.
Can't file: URLs link to jar:file: URLs?  The attacker might have to place a jar on the hard drive as well as an HTML file, but given bug 230606 and bug 209234, even placing a jar in the cache is sufficient...
Why don't we disallow enableprivilege by default for signed JARs too?
because signed jars is how you implement enablePrivilege, unless you turn on the "during-development-only" codebase pref.  I'm not totally against killing enablePrivilege entirely, but that wouldn't be this bug.

Re: comment 19. Those others are bugs we should fix, that doesn't mean we don't fix this one. Fixing this one raises the bar considerably.
Assignee: dveditz → nobody
The enablePrivilege dialog is gone now (removed in bug 750859).
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: