163767 - (noexternalprotocol) [URL] Pref to disable external protocol handlers (e.g. in Windows registry)

Status: VERIFIED DUPLICATE of bug 173010

(Core :: Networking, defect, P2)

Description

[Ben Bucksch (:BenB)]

Given the recent hcp: exploit in Windows XP [1] and explected future exploits,
allowing any registered protocol in the Windows registry is a time bomb. I can
see that many people will want the functionality (that's what it's for, I
guess), but some users will feel very uncomfortable, if any installed
application could possibly the base for an attack. That makes securing the
system way harder. A major selling point for Mozilla and against MSIE is that it
is not integrated that much with Windows.

Add a pref so that the user can disable the lookup of protocol handlers outside
of Mozilla. A pref to selectively enable some of these protocol handlers would
be good (and it very cheap).

nsIOService, line 460 (thanks to d|ver):

If we just remove the NS_FAILED expression, we disable all external protocol
handlers that are not explicitly enabled via a boolean pref
"network.protocol-handler.external.<scheme>".

Quick code:

After:
447         rv = prefBranch->GetBoolPref(externalProtocolPref.get(),
&externalProtocol);
448         if (NS_FAILED(rv))
449             externalProtocol = PR_FALSE;
insert:
 PRBool useExternal = PR_TRUE;
 rv = prefBranch->GetBoolPref(externalProtocolPref.get(), &externalProtocol);

then replace:
460     if (externalProtocol || NS_FAILED(rv)) 
with:
if (externalProtocol || (NS_FAILED(rv) && useExternal)) 

That should do the trick. Obviously, that's totally untested. I don't have a
Windows compiler either to test it.

I need that for Beonex Communicator.

[1] <http://online.securityfocus.com/archive/1/287482/2002-08-10/2002-08-16/0>

Comment 1

[Ben Bucksch (:BenB)]

eh,
rv = prefBranch->GetBoolPref(externalProtocolPref.get(), &externalProtocol);
shoudl of course read 
rv =
prefBranch->GetBoolPref(NS_LITERAL_STRING("network.useAnyExternalProtocolHandler"),
&useExternal);

Comment 2

[benc]

Sounds like a good idea to me. This might be good to implement in all plaforms
as well...

Comment 3

[Ben Bucksch (:BenB)]

This *is* XP code.

Comment 4

[Ben Bucksch (:BenB)]

Attachment: Possible Fix, version 1

This compiles on Linux, but it's still untested. Somebody on Win32 please test,
if it works as specified.

Try e.g. the following:
1. Pick an uncommon URL scheme that you have a protocol handler for in the
Windows registry and that you can trigger, e.g. hcp:.
2. Create a web page with such a URL.
5. Start Mozilla without any new prefs, click on URL. Expected: the registered
app should come up.
6. Shutdown Mozilla, add prefs:
network.protocol-handler.useOtherExternal, false
network.protocol-handler.external.hcp, false  (if you chose hcp:)
7. Start Mozilla, click on URL. Expected: the registered app should *not* come
up.
8. Try out other combinations of the prefs in step 6. Any other combination
should show no change from the state before the patch.

Comment 5

[Ben Bucksch (:BenB)]

s/useOtherExternal/useAnyExternal/

Comment 6

[Sebastian Biallas]

*** Bug 163648 has been marked as a duplicate of this bug. ***

Comment 7

[Sebastian Biallas]

According to bug 163648, this also applies to vbscript: URLs with (at least)
Win2000/NT and Win98.

Comment 8

[Manko]

Please, change severity of this bug to CRITICAL according to bug 163648, because
we can get a lot of security problems.

More, I think, external protocols must be disabled on default.

Comment 9

[Ben Bucksch (:BenB)]

I think that you can delete the offending protocol handlers out of the Windowes
registry, so there is a workaround.
A full-blown UIis going to be hard, because we'll have to enumerate all
available protocols handlers in the prefs dialog and offer a checkbox/listitem
for each of them to allow users to selectively enable certain external protocol
handlers.

Comment 10

[Manko]

>I think that you can delete the offending protocol handlers out of
>the Windowes registry, so there is a workaround
Oh, why must I edit registry to make my browser safe?

More, "vbscript:" is probably required for internal Windows needs
(MSHTML+VBScript engine is used in Microsoft Management Console and many other
system utilities), and registry hacking can violate system control abilities.

Comment 11

[Ben Bucksch (:BenB)]

OK.

Comment 12

[Ben Bucksch (:BenB)]

BTW: The protocol handler selection should now work like the following:
1. If the network.protocol-handler.external.<scheme> pref is true, use that
external protocol handler
2. If Mozilla has an internal protocol handler, use that
3. If network.protocol-handler.useOtherExternal is true (that's the default),
then use any external protocol handler you can find.

Comment 13

[Manko]

We must understand, what did we add external protocol support for?
Previous versions of Mozilla (including 1.1b) didn't it, and I was not a bit
suffering from it.

Internal protocol handlers - (http:,mailto:,news:,javascript: etc.) - no
problem. Maybe, Mozilla plugins, such as RealAudio, might add another protocols
and register it in Mozilla configuration files.

But other protocols, which have no any relation to Mozilla componets and
plugins, must be disabled - otherwise we shall go on a way of the Microsoft,
aspiring to grasp immense and to push everything in their Internet Explorer.

Comment 14

[David Bradley]

I tried the patch. I put the stuff below in my user.js and still was able to
bring up media player using the mms protocol. mmm://test.com

user_pref("network.protocol-handler.useOtherExternal", false);
user_pref("network.protocol-handler.external.mms", false);

I think I did everything correctly.

Comment 15

[Ben Bucksch (:BenB)]

Attachment: Possible Fix, version 2

Return error when blocking. Probably prevents a crash.

Comment 16

[benc]

Is your patch the first implementation of this, or modifying the existing prefs
that are supported? 

I'm working on URL scheme test cases right now, so I'm hoping you are going to
say that the scheme handling is caps insensitive, as well as handling other
aspects of scheme formating:

(from RFC 2396:)

     scheme        = alpha *( alpha | digit | "+" | "-" | "." 

Does anyone know how well the punctuation will work in a pref?

Comment 17

[Jesse Ruderman]

This is a request for a pref that would be hidden and off by default, so it is 
not critical.  I have reopened bug 163648, 
"URL with vbscript: protocol launches MS Internet Explorer", for a less drastic 
change to the default behavior.

Comment 18

[Ben Bucksch (:BenB)]

benc, you raise valid problems, but that's not exactly what this bug is about,
it just makes them more obvious. The scheme-specific prefs are already there, I
just added the useAnyExternal pref.

I do intend to make some sort of limited UI for this, I am just not sure how.

Comment 19

[David Bradley]

Ok, the last patch seems to work. Here's what I saw

No change to prefs MMS protocol doesn't work
Set *.external.mms to true and MMS worked
set *.useAnyExternal to true and MMS worked
set both to true and MMS worked
set both to false and MMS doesn't work

One concern I have is that when useAnyExternal is absent or false we say the
protocol isn't registered, which isn't exactly true. I can see this creating
confusion for users. I know it's more work, but there probably should be a
separate error message for this, rather than just reusing the protocol not
registered one.

Comment 20

[Ben Bucksch (:BenB)]

Thanks David Bradley for testing this! :-)

> No change to prefs MMS protocol doesn't work

hm, it was supposed to work in this case. I don't know what happens. But I guess
adding a default pref (useAnyExternal to true) fixes it in any case.

Comment 21

[David Bradley]

The pref got stored in prefs.js after I had set it in my user.js. Once I removed
them from there, it worked like you stated.

This isn't the result of your patch, but the error paths are a little hard to
follow in the code. For instance the:

if (externalProtocol || (NS_FAILED(rv) && useAnyExternal) 

could be testing the rv of the GetBoolPref or the CallGetService, depending on
the useAnyExternal pref.

Comment 22

[Ben Bucksch (:BenB)]

Attachment: Possible Fix, version 3

True. Making error path explicit.

Comment 23

[Ben Bucksch (:BenB)]

Attachment: Possible Fix, version 3

Ops, attached wrong patch. Ignore the last one.

Comment 24

[benc]

(I've moved the scheme syntax concerns to bug 164153.)

Comment 25

[Manko]

Dark side of the moon is using non-standard protocols in <iframe src="...">

See
http://bugzilla.mozilla.org/attachment.cgi?id=96135&action=view
for example.

(Caution! When you click this link, 64 MSIE windows will pop up.
Be carefully! Javascript can be turned off, exploit still works. You can get this
code even by e-mail.)

I think, non-standart protocols must be strongly disabled in <iframe src=>, <img
src=>, <object data=> ant other similar cases. It might be enabled only in <a
href=> construction, but only after user confirmation.

Comment 26

[Manko]

Attachment: Proposed UI to launching URLs with external protocol

Comment 27

[Daniel Veditz [:dveditz]]

Note there is already a pref "network.protocols.useSystemDefaults" (default
false), but it's only looked at in docshell and not where we actually need it.
You might want to remove that one or combine it with the prefs you're working on.

Darin: you, Mitch and I were looking at URIloader, Ben's poking at IOService.
Which is a better place to trap these in your Necko design?

Comment 28

[Sven Krohlas]

Well, a more general comment:
Why do we need to support starting another application, when we stumble over an
external protocol?

I see the following advatage:
-It's easier for the user

BUT:
-As we see in bug 163648 it can be a severe security problem.
(and if there's a security problem in another app that can be exploited using
Mozilla users will say thet it's Mozillas fault)
-Every experienced users is able to start his software for an external protocol
himself, so he simply doesn't need this feature. And so he should also be aware
of the consequences.
-Non-experienced users usually don't use "exotic" protocols, so why should they
need such a feature?

An UI for this is not a solution, as mentioned in
http://bugzilla.mozilla.org/show_bug.cgi?id=163648#c19
unexperienced users could make a wrong selection, and i see no way to explain
to them what an external protocol is...

I think [e-mail] is right about it:
(http://bugzilla.mozilla.org/show_bug.cgi?id=163767#c25)
IMHO we should even disable it in _all_ cases, due to the reasons above.

btw: will there be a version 1.1.1 with a fix for this?

Comment 29

[Darin Fisher]

IOService is a good catch-all i think.  URL strings get converted to nsIURI
objects via nsIOService, and that is where we decide to talk to the default
protocol handler when we encounter an unknown protocol scheme.

Comment 30

[Boris Zbarsky [:bzbarsky]]

> Why do we need to support starting another application, when we stumble over an
> external protocol?

So that streaming medial players (realplayer in particular) will work correctly.

This is just like asking why we need to start another application when we
encounter a type we don't handle internally or via plugin...

Comment 31

[Darin Fisher]

then those streaming media players are currently broken on linux because we
ignore unknown protocol schemes under linux.  seems mac, windows, and os2 each
resort to launching external apps.

Comment 32

[Boris Zbarsky [:bzbarsky]]

You're right, they are broken on Linux.  This is not exactly a good thing...

Comment 33

[Manko]

I think, realisation of streaming protocols is not so hard thing without calling
non-internal protocols. Typical scheme might be as follows.

0. Streaming application, such as WinAmp, installs as plugin to handle specific
MIME-type (e.g. WinAmp playlist - "audio/mpegurl").
1. Webmaster puts in a page link to playlist with URL, beginning with "http://".
2. Mozilla user clicks on this link and Mozilla sends corresponding HTTP request.
3. Web-server in HTTP response headers puts "Content-Type: audio/mpegurl"
4. Mozilla calls WinAmp plugin and transmits to it data from URL. This data (in
our case, playlist) may contain URLs with internal WinAmp protocols.
5. WinAmp plays streaming content from URLs contained in playlist.

I think, this is safe and pellucid alternative in comparison with calling
non-internal protocols directly from Mozilla.

Comment 34

[Boris Zbarsky [:bzbarsky]]

> 0. Streaming application, such as WinAmp, installs as plugin to handle specific
> MIME-type (e.g. WinAmp playlist - "audio/mpegurl").

This requires control over said streaming app.  Which we do not have.  "As
plugin" has its own issues, btw, like running in the same process space as the
browser....  

Comment 35

[Manko]

You're quite right. This issue was persisting always, vulnerabilities in Flash
plugin demonstrate it, see
http://online.securityfocus.com/bid/5429
http://online.securityfocus.com/bid/5445

But if user installs one or another plugin, he understands that if his system
will be cracked via similar vulns, it will be guilt of plugin, not a browser.

More, if we will add plugin manager and undesirable content blocker (see
bug 19118, bug 70805, bug 94035 and bug 147866), users will can turn off
vulnerable plugins and potentially dangerous content.

Comment 36

[Manko]

Another consideration - by now plugins can be (and are by default) disabled in
e-mail messages. This prevents using plugin vulnerabilities for personalized
attacks.

Comment 37

[Sven Krohlas]

For me it was always the following: if my browser doesn't understand the
protocol or file type it tries to find a plug-in who can cope with it. If it
can't find one, then I get a error message or asks me to save the file.
That's the way it was working, and that's the way it should work.

A user should be able to cut and paste a link into another application if he
likes to view things linked by protocols Mozilla and its plug-ins can't handle.
If we have a look at the registry to find a corresponding application (and I'm
strongly against it) it should look like the following:
"Mozilla can't cope with the URL you opened. But we found another application on
your computer which could. Shall we open this links using <application>?
WARNING: This could be a severe security problem. <scenario about ww3> <another
scenario about erased harddisks>"
This isn't what we want, is it?

If a user want's to use such protocols he should install a plug-in or configure
it manually (there is at least a UI for filetypes, we could add another one
for protocols, _maybe_ with a "Add from registry"-button and the warning above),
but don't trust the windows registry per default and give him a one click way to
trash his computer (Loveletter was written completely in vbscript, iirc...).

There is a reason I recommend Mozilla to my friends: security. And they slowly
start to understand what it means, since some virii were happyly exchanged
between them via Outlook. Now some of them don't use Outlook anymore (you may
guess what they are using now :) If they catch the fact, thet we can have the
same (or nearly) problems in Mozilla, why should they use it?

If some Mozilla distributors want this feature: just take the code and add it.
But they won't get happy with it.

just my 0.02¤

Comment 38

[Ben Bucksch (:BenB)]

> I think, [using external apps for file types] is safe and pellucid alternative
> in comparison with calling non-internal protocols directly from Mozilla.

No, it is not. Calling external apps with data from the net is dangerous, no
matter, if using strange protocols or file types. Consider MS Word macro viruses...

I don't see a need to get political in this bug. Add the pref, default it to use
external protocols, make a UI, and we can be all happy. If you want security,
use Beonex Communicator (or let your friends use it) :-). If that's not enough
for you, please open another bug to argue about the default pref.

Comment 39

[Manko]

>Add the pref, default it to use external protocols,
>make a UI, and we can be all happy
Main question is: for what, generally, we need to use external non-standard
protocols? And do we nead it at all?

For streaming broadcast (RealAudio, WinAmp) we have plugins, for desktop
integration (such as OEone desktop) developers can write their own RDF and XPCOM
modules.

So, please, tell me your reasons for this dubious "feature".

Comment 40

[Boris Zbarsky [:bzbarsky]]

> For streaming broadcast (RealAudio, WinAmp) we have plugins

Which very often lag far behind the standalone players in functionality...  The
point is, we should not be forcing everyone (think, eg, IRC applications) to be
implemented as a friggin' browser plugin (let's not even start on incompatible
pluging APIs) just so users can access a protocol that that application supports.

Should we have a way to turn this off?  Yes.  Should we maybe block particular
protocols known to be "harmful" by default?  Yes.  Should we turn this off
completely with no way to enable it?  Absolutely not.

Comment 41

[Manko]

On the other hand:
Should we enable external protocols in <iframe src=>, <img src=> etc.?
Absolutely not.
Should we enable external protocols in mail & news?
Absolutely not.
Should we ask confirmation with notice that might be unsecure, if user clicks on
a link to external protocol?
Absolutely yes.
Should we disable this feature until these three questions aren't resolved surely?
Absolutely yes.

Isn't it?

Comment 42

[Ben Bucksch (:BenB)]

manko,
stop arguing about the default in this bug. Again: File a new bug, if you want
to have external protocols disabled by default. Since some people will want to
have them all enabled by default, we will have a pref for it in any case. So,
nothing you say here will change anything of the patch I supplied and will only
hold things up by forcing people to read a long discussion (or running away
before reading anything) instead of reviewing it.
BTW: The screenshot you attached has absolutely nothing to do with my patch.

Developers:
This is reported to work on Win32. Please review, including compiling and
testing it again on Win32 (and preferably Mac, just in case).

Comment 43

[bugs]

Why is this different from downloading a document with a registered MIME type,
and asking what Mozilla should do in the dialog below?

You have chosen to download a file of type: xxx/xxx from URL
What should Mozilla do with this file?
() Open using an application
() Save this file to disk

[] Always ask before opening this type of file

I think the problem is the same, the only difference is that the protocol
handlers don't need the cooperation of the server (MIME types configuration).

Just edit the text appropriately, and replace the Save option with "Copy the URL
to the clipboard" (what I will request adding to the default download dialog anyway)

Comment 44

[Ben Bucksch (:BenB)]

lamer, that's all nice, bug *this* bug is about my patch (and maybe a UI for
it), nothing else. Unless you have strong argument why this patch should not be
accepted, please just file a new bug about alternative
suggestions/designs/implementations and only reference it here.

Comment 45

[bugs]

Sorry for that, I opened a new bug for it, bug 167473.
BTW the "Copy the URL" bug is bug 152188.

Comment 46

[Manko]

I have filled bug 167475 (Disable external protocol handlers in all cases,
excluding <A HREF=>) to more discussion about external protocols.

Comment 47

[Ben Bucksch (:BenB)]

Attachment: Proposed Fix, Version 4

In response to dveditz' comment 27, I agree that useSystemDefaults is a better
wording. However, the pref mentioned cannot be reused. It sounds that way, but
it's worded wrongly. Could we please go away from the wording "protocol" here,
which doesn't really fit in either case, and use "mimetype" and "url scheme"
instead? "tel" is not a protocol, after all, and SVG is *definitely* not a
protocol either.

+pref("network.protocol-handler.useSystemDefaults", true); // this is for url
schemes. ask the OS - or don't. a lot of dangerous crap might be there (Windows
Help with potential exploits), but some useful stuff as well (RealPlayer).
+pref("network.protocols.useSystemDefaults", false); // *headbang* this is not
for protocols or url schemes, but mimetypes.
-pref("network.protocols.useSystemDefaults",   false); // set to true if user
links should use system default handlers


I am attaching a new patch, against the current 1.0 branch (my patch conflicted
with another patch to explicitly disable certain url schemes). It also includes
the default prefs as cited above (i.e. true).

The patch is again untested, because I don't have a Windows build environment.
Reviewer, please do that.

Comment 48

[Ben Bucksch (:BenB)]

Attachment: all.js which sets default to false

Here is the all.js version I use for Beonex Communicator. It sets the default
to falsle and expcitily enables a few well-known url schemes.

Comment 49

[Darin Fisher]

ben: sorry for delaying on reviewing your patch... i've been swamped, and now
i'm going on vacation.  i should get to this at the latest by the first week of
the new year.  sorry!!

Comment 50

[Ben Bucksch (:BenB)]

darin, that's ok. have happy holidays :-)

Comment 51

[Darin Fisher]

Comment on attachment 109340 [details] [diff] [review]
Proposed Fix, Version 4

i'm really sorry that this slipped off my radar for so many moons...

i don't think a whitelist of allowed protocols is a good idea.	it limits our
compatibility with the OS.  we'll never be able to ship a default whitelist
that works for everyone.

i would be interested in limiting the places where external URI types can be
used.  i think user initiated link clicks should almost always be allowed. 
but, i don't think it makes any sense for iframes or img tags to be able to
cause external URLs to load.  i know this is a far more difficult problem to
solve, but i think it breaks too much functionality if we try to support a
whitelist.

just consider all the protocol schemes supported by gnome-vfs that we current
support indirectly via gconf/gnome/nautilus.

plus, we've lived with a blacklist for a long time, and it hasn't been a
problem so far.

that said, i can understand that you might want to configure an instance of
gecko to allow only a whitelist of external protocols.	in that case, i would
be willing to accept some sort of patch.  and if you want to do that, no
problem.  but, you're going to need to revise this patch since it is very much
out of date.  (blame me for that!)

Comment 52

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Check this out. Major vulnerability in "ms-its" protocol.

http://www.us-cert.gov/cas/techalerts/TA04-099A.html

Comment 53

[Christian :Biesinger (don't email me, ping me on IRC)]

iirc dveditz was arguing for a whitelist instead of a blacklist. this bug seems
to be about that.

Comment 54

[Manko]

Bug 250180 - yet another example why we must fix this bug.

Comment 55

[Alexey Chernyak]

Apparently Microsoft is doing the same for IE with WinXP SP2?

Comment 56

[Daniel Veditz [:dveditz]]

Did my fix for bug 173010 basically resolve this? I used a slightly different
pref name but seems to be more or less what this bug is about.

Comment 57

[Darin Fisher]

FWIW, i'm pro-whitelist now ;-)  what i like about dveditz's approach is that it
prompts the user with a warning dialog when unknown protocols are encountered. 
so, as a result we can mark some protocols as always being allowed, others as
never being allowed, and for the remainder the user is prompted.  that feels
like the right compromise between functionality and user protection to me.

Comment 58

[Ben Bucksch (:BenB)]

Thanks. IMHO, it would have been nice, if Mozilla could have used this
protection in the last 2 years (and thus have 2 security holes less), but
dveditz' patch seems to be vastly superiour
- for the reasons you mention (prompt user),
- it still allowes per pref to block unknown schemes without asking the user
  (like mine did), and
- his next version will be in a better code place, making it work in more
  edge cases.
Thus, DUPping.

*** This bug has been marked as a duplicate of 173010 ***

Comment 59

[benc]

V/dupe.

I've always been pro-whitelist because without doing so, we put our security at
the mercy of whatever installs on the OS. Before it used to be just Microsoft
(or sometimes Apple) doing insecure things. But w/ spyware, the situation is
really out of control.

Even a whitelist has limitations, because on more obscure protocols, there is no
reason why spyware would not simply hijack a protocol handler when it installs.

Comment 60

[Daniel Veditz [:dveditz]]

If spyware is installed all bets are off, you lose.

The protocol warning is because even legitimate default handlers may have
undiscovered exploits that remote content might someday use in an attempt to get
installed or cause harm. The warning is just a speedbump that might help protect
some fraction of our users. To be truly safe you should turn off all handlers
(this bug request), which we now have an option for as well.