440892 - network.protocol-handler.warn-external are ignored

Status: NEW

(Firefox :: File Handling, defect, P3)

Description

[Daniel Veditz [:dveditz]]

Post on full-disclosure claims the network.protocol-handler.warn-external prefs are ignored:

> From: carl hardwick <hardwick.carl_at_gmail.com>
> Date: Wed, 18 Jun 2008 17:22:51 +0200
> 
> these protocol-handler security settings are ignored although they're
> set to 'true' and no warnings are shown:
> 
> network.protocol-handler.warn-external.mailto
> network.protocol-handler.warn-external.news
> network.protocol-handler.warn-external.nntp
> network.protocol-handler.warn-external.snews
> (in about:config)
> 
> For example,
> I set network.protocol-handler.warn-external.mailto to 'true', clicked
> on an e-mail link and Windows Mail is launched without any warnings
> (tested on Firefox 3.0 on Windows Vista SP1)

http://seclists.org/fulldisclosure/2008/Jun/0228.html

My reply was that the new external protocol handling takes over, and if you've selected something that takes over (managed on the "Applications" tab of Firefox preferences). Dmose said that it was not intended to override these prefs -- just because you want a particular action to happen doesn't mean you don't want the chance to intercept it.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

I don't think that's quite it either.  My recollection is that warn-external always supposed to be consulted, until such time as the user explicitly selects the "Remember my choice for foo: links" checkbox.  Thereafter, that pref shouldn't be consulted at all.

Comment 2

[Shawn Wilsher :sdwilsh]

always ask is *always* checked.  On top of that, we only load without asking if the preferred action is set to use a helper app or the system default.  Relevant code is here:
http://hg.mozilla.org/mozilla-central/?annotate/tip/uriloader/exthandler/nsExternalHelperAppService.cpp#l819

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking; also perhaps WFM or INVALID?

Comment 4

[Justin Dolske [:Dolske]]

(not actively working on this)

Comment 5

[Mike Perry]

Just FYI, the torbutton addon was depending upon these prefs to prevent
automatic launch of applications that can bypass proxy settings. In Torbutton, we fix it by wrapping @mozilla.org/uriloader/external-helper-app-service;1 and @mozilla.org/uriloader/external-protocol-service;1. The code is at https://tor-svn.freehaven.net/svn/torbutton/trunk/src/components/external-app-blocker.js if anyone needs it who has run into this bug for their addons.

In general, ignoring these prefs can also cause security issues with auto-launching of malicious document formats exploiting particular 
applications for code execution as well... It might be worth either fixing the prefs or completely removing them so as to eliminate the false sense of security they provide.

Comment 6

[Tom Hessman]

I agree with comment 5...it is definitely worth fixing the prefs because of potential security issues, and if nothing else the prefs give a false sense of security since they are no longer consulted but people still assume they are.  I realize that in many (if not most) cases the new dialog that asks you to choose an app is used, but not in all cases!  When I tested this on a Fedora system, for example, clicking a mailto link launched Evolution without asking, with default profile settings.  I also tried this in combination with the pref "browser.helperApps.alwaysAsk.force", which I assumed would force the app chooser dialog to always appear, but that wasn't the case either...it still launched Evolution!

Personally, in addition to the security benefits, I also consider these prefs to be an annoyance blocker, because it is very frustrating to click on a link without realizing it's a mailto link and having to wait while Thunderbird launches and tries to load 5 e-mail accounts and over 40 RSS feeds all at once.

At the very least, as stated in comment 5, these prefs should be removed if they aren't going to be used anymore, because people don't realize that and have a false sense of security.  Of course, it would be much more ideal to respect these preferences as has been done for as long as I can remember (from at least Firefox 1.0 (I assume much earlier) up until Firefox 3).  These prefs should override any other user-chosen settings, because they are prefs that would be explicitly enabled by a user.

BTW, this bug applies to all platforms (I have personally seen it on Mac OS X, Fedora 11, and Windows XP), so the platform should be updated accordingly.

Comment 7

[Pander]

For years I was wondering why Thunderbird would not open https:// links. I thought this had to do something with settings in GNOME for default applications etc. However recetly, I started looking inside the prefs.js file of Thunderbird version 2.0.0.23.

There I found:
  prefs.js:user_pref("network.protocol-handler.external.https", false);
and changed it to:
  prefs.js:user_pref("network.protocol-handler.external.https", true);
to get it working.

According to me, all the network.protocol-handler.warn-external, like the ones mentioned above, should be easily controllable by the user via the Preferences dialog.

Comment 8

[Shawn Wilsher :sdwilsh]

(In reply to comment #7)
> According to me, all the network.protocol-handler.warn-external, like the ones
> mentioned above, should be easily controllable by the user via the Preferences
> dialog.
You didn't mention any warn-external preferences.  I think you have this bug confused with something else.

Comment 9

[Pander]

Oops, indeed. I posted in wrong issue. Sorry and please ignore comment #7.

Comment 11

[Biju]

(In reply to comment #6)
> I agree with comment 5...it is definitely worth fixing the prefs because of
> potential security issues, and if nothing else the prefs give a false sense of

correct see http://bit.ly/????  URL at Bug 599662 comment 0

Comment 12

[shawn.sumin]

The Tor Project / Electronic Frontier Foundation is paying to have this bug
fixed.

"If you know C++ and/or Firefox internals, we should be able to pay you for
your time to address these issues and shepherd the relevant patches through
Mozilla's review process."

Source:
https://blog.torproject.org/blog/web-developers-and-firefox-hackers-help-us-firefox-4

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

>My recollection is that warn-external
>always supposed to be consulted, until such time as the user explicitly selects
>the "Remember my choice for foo: links" checkbox.  Thereafter, that pref
>shouldn't be consulted at all.

or the user proactively selects a choice other than "Always Ask" in the applications pref pane, those would be the only two cases.

Comment 14

[Mike Kaply [:mkaply]]

So what do people think the final outcome of this should be?

The prefs are definitely not used (even though they are referenced in code)

Even if you delete mimeTypes.rdf completely (which in theory should make it uses the preferences), they don't get used, because mimeTypes.rdf gets recreated with default values for alwaysAsk.

Relevant code here:

http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/nsHandlerService.js#380

So the fact is these prefs don't get used.

Personally I think the prefs should override the values in mimetypes.rdf because it's easier for an admin to control.

Comment 15

[[e-mail]]

I ran into this issue on Arch Linux, Thunderbird 45.1.0

Comment 16

[Stefan]

I ran into this issue on Arch Linux. http/https-Links got always opened with midori, instead of firefox. 
I searched around for years, only found unhelpful sites like http://kb.mozillazine.org/Network.protocol-handler.external.%28protocol%29 and http://kb.mozillazine.org/Changing_the_web_browser_invoked_by_Thunderbird. 
Finally I solved configuration problem with editor in file mimeTypes.rdf, where I changed midori entries to firefox entries.