Last Comment Bug 167475 - [URL] Disable external and returning no data protocol handlers in all cases, excluding <A HREF=>
: [URL] Disable external and returning no data protocol handlers in all cases, ...
: privacy, sec-want
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
-- critical with 18 votes (vote)
: ---
Assigned To: timeless
: Andrew Overholt [:overholt]
: 213280 243503 244205 379804 660851 (view as bug list)
Depends on: 379803 173010 229168 379819
Blocks: 334426 lastmeasure eviltraps AntiFingerprinting 163648 172498 213280 356638
  Show dependency treegraph
Reported: 2002-09-09 04:41 PDT by Manko
Modified: 2017-01-10 08:20 PST (History)
45 users (show)
bugs: blocking‑aviary1.0PR-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

draft (787 bytes, patch)
2010-03-22 13:41 PDT, timeless
cbiesinger: review+
Details | Diff | Splinter Review

Description User image Manko 2002-09-09 04:41:02 PDT
As we can see in bug 163648, external protocols can cause a lot of security
issues. But exploits for this bug are dangerous mainly if external protocol
handler is being requested automatically from HTML code via <IMG
SRC="externalprotocol:URL">, <IFRAME SRC="externalprotocol:URL"> and other
similar cases.

More, with relation to common sense, invoking an external protocol is absurd in
this case, because <ANYTAG SRC="..."> is request to return some data in browser,
not for launch external application.

So, disable external protocols in all cases, excluding <A HREF=>, can solve this

Marking severity critical according to 163648.
Comment 1 User image Manko 2002-09-09 05:32:12 PDT
Another way to exploit URL with external protocols might be using Javascript.
Therefore, we must disaple external protocols in JS operators:
Comment 2 User image Jesse Ruderman 2002-09-11 16:58:51 PDT
It's not hard for a malicious site to get a visitor to click a link.  Requiring
a click or an equivalent keyboard action can be useful for limiting how much a
web site can annoy you (pop-up windows, etc.) but I don't think it's useful for
larger security issues.
Comment 3 User image Daniel Veditz [:dveditz] 2002-09-11 17:25:47 PDT
I agree, WONTFIX. Other bugs are already discussing blocking external protocol
handlers, we don't need to do additional work to base the decision on context.
Comment 4 User image Manko 2002-09-11 23:43:36 PDT
I can't agree with WONTFIX. Have we at least one reason for enabling external
protocols in <IFRAME SRC> or <IMG SRC>?

Assuming that user has enabled some protocol, for example, irc: to start IRC
chat by pressing a link. He has opened web page with HTML code:
<iframe|img src="irc:some.url.there">. And he has seen IRC window to appear on
screen suddenly (without his deliberate request or confirmation) and empty
iframe (or broken image icon in case <IMG SRC=>) in page. Absurd, isn't it?

More, imagine that you have received HTML email with such code...
Comment 5 User image Daniel Veditz [:dveditz] 2002-09-12 11:35:17 PDT
re-opening for reconsideration. This doesn't solve the problem of untrusted
protocols, but even for trusted ones it doesn't make much sense in these kinds
of places.
Comment 6 User image Manko 2002-09-12 23:37:38 PDT
Changing severity from enhancemet to normal - it isn't enhancement anyway.
Comment 7 User image Daniel Veditz [:dveditz] 2002-09-13 10:15:18 PDT
It is working as-designed, you would like a change == enhancement. enhancement
doesn't mean "less than trivial" despite the position on the severity list, it's
really a different kind of bug report. Enhancements can be quite important.

--> darin who had some ideas how we could do this, although the changes probably
aren't in necko land.
Comment 8 User image Matthias Versen [:Matti] 2002-10-03 20:16:09 PDT
*** Bug 172498 has been marked as a duplicate of this bug. ***
Comment 9 User image Manko 2002-10-04 00:22:27 PDT
I would propose my guess-work to solve this problem. Sorry if I don't understand
this issue correctly, this is only my imhoes and afaiks ;)

Before implementing external protocols Mozilla did follow this algorithm:
+-----------------------+    +-------------------------------------+
| User clicks on a link |    |  HTML tag refers to external object |
+-----------------------+    +-------------------------------------+
                   |               |
           /                                \
  +--yes--< Is this is an internal protocol? >--no---+
  |        \                                /        |
  |         \------------------------------/         |
  |                                                  |
  V                                                  V
+----------------------------+                  +--------+
| Call Necko to request data |                  | Ignore |
+----------------------------+                  +--------+

This algorithm Mozilla does follow now:
+-----------------------+    +-------------------------------------+
| User clicks on a link |    | HTML object refers to external data |
+-----------------------+    +-------------------------------------+
                   |               |
           /                                \
  +--yes--< Is this is an internal protocol? >--no--+
  |        \                                /       |
  |         \------------------------------/        |
  |                                                 |
  V                                                 V
+----------------------------+      +--------------------------------+
| Call Necko to request data |      | Call external protocol handler |
+----------------------------+      +--------------------------------+

Proposed algorithm:
+-----------------------+        +-------------------------------------+
| User clicks on a link |        | HTML object refers to external data |
+-----------------------+        +-------------------------------------+
             |                                                    |
             V                                                    |
            /---------------------------\                         |
           /                             \                        |
  +--yes--< Is this an internal protocol? >--no--+                |
  |        \                             /       |                |
  |         \---------------------------/        V                |
  |                                       +-------------------+   |
  |                                       | User confirmation |   |
  |                                       | (see bug 167473)  |   |
  |                                       +-------------------+   |
  |                                              |                |
  |                                              V                |
  |                          +--------------------------------+   |
  |                          | Call external protocol handler |   |
  |                          +--------------------------------+   |
  |                                                               |
  |                                  +--------------------------- +
  |                                  |
  |                                  V
  |             /------------------------------\
  |            /                                \
  |   +--yes--< Is this is an internal protocol? >--no--+
  |   |        \                                /       |
  |   |         \------------------------------/        |
  |   |                                                 |
  V   V                                                 V
+----------------------------+                     +--------+
| Call Necko to request data |                     | Ignore |
+----------------------------+                     +--------+

How do you think, is it correct?

Comment 10 User image Darin Fisher 2002-10-04 09:55:34 PDT
this sounds like 1.2 fodder, no?
Comment 11 User image Matthew Middleton (:zzxc) 2002-10-04 12:23:05 PDT
This is very important to be fixed ASAP with the recent windows xp flaw that
allows an hcp protocol request to delete any file on your hard disk, wildcards
allowed.  See bug 172498 for an explanation.  Note: that bug was marked as a
dupe of this broader one.  An exploit which will delete everything in
"c:\delthis" with an image tag is included on that bug.
Comment 12 User image Darin Fisher 2002-10-11 00:26:52 PDT
now that we have a suitable blacklist in place (bug 163648 has been fixed), this
bug is much less urgent.  pushing out to moz 1.3.
Comment 13 User image Darin Fisher 2002-11-23 19:35:20 PST
cc'ing bzbarsky since he's done some recent work w/ the unknown protocol handler.
Comment 14 User image Boris Zbarsky [:bz] (still a bit busy) 2002-11-23 19:44:35 PST
Hmm.... Link clicks call InternalLoad directly.  So we could throttle this in
nsDocShell::LoadURI, perhaps.  Of course if the user types such a URI in the URL
bar we had better load it...
Comment 15 User image Darin Fisher 2002-11-25 15:21:47 PST
-> future (if someone wants to own this, please let me know!)
Comment 16 User image benc 2003-04-19 10:31:22 PDT
-> docshell per bz's comment.
Comment 17 User image Boris Zbarsky [:bz] (still a bit busy) 2003-04-19 10:52:55 PDT
Docshell can't throttle <img> loads.  We need a more general solution.
Comment 18 User image Adam Hauner 2004-05-13 10:32:43 PDT
*** Bug 243503 has been marked as a duplicate of this bug. ***
Comment 19 User image Boris Zbarsky [:bz] (still a bit busy) 2004-05-20 15:20:14 PDT
*** Bug 244205 has been marked as a duplicate of this bug. ***
Comment 20 User image Boris Zbarsky [:bz] (still a bit busy) 2004-05-20 15:30:40 PDT
This wouldn't be too hard to do with the flag proposed in bug 229168 -- we'd
just not load things with that flag set in places where content is expected
(most places).
Comment 21 User image Tom Graham 2004-07-08 10:15:08 PDT
Requesting review for 1.0
Comment 22 User image Manko 2004-07-09 00:27:47 PDT
Changing priority according bug 250180: we'll have more security issues until
tyhis will be fixed.

Changing dependencies: bug 229168 is depending on this, not vice versa.
Comment 23 User image Manko 2004-07-09 00:37:28 PDT
Oh, sorry, logically i'm right, but bug 229168 have a patch to do this. Begging
your pardons.
Comment 24 User image penguinista 2004-07-09 15:55:54 PDT
Why not add a whitelist for external handlers, similar to the cookie 
whitelist? The prompting could be similar too... For example: 
The site has requested to open external protocol shell. 
[ ] Use my choice for all external protocol requests from this site. 
[Show Details] [Allow] [Allow for Session] [Deny] 
Clicking "Show Details" might provide the argument information and anything 
else that would be relevant. 
Thoughts? This would seem to solve all of the external protocol handler issues 
in one fell swoop, IMO. :) 
Comment 25 User image Andrew Hagen 2004-07-10 07:20:54 PDT
Whitelist is bug 173010.
Comment 26 User image Daniel Veditz [:dveditz] 2004-07-10 15:09:06 PDT
Adding whiteboard comment to hopefully redirect folks to the real whitelist bug.

assigning to me since I don't think Adam's going to be working on this.
Comment 27 User image Jesse Ruderman 2006-04-18 05:43:42 PDT
See also bug 334426 (especially comments 2 and 3) and bug 266325.
Comment 28 User image Daniel Veditz [:dveditz] 2006-04-18 10:55:13 PDT
(In reply to comment #27)
> See also bug 334426 (especially comments 2 and 3) and bug 266325.

Thanks Jesse, this is the one I was thinking of.

How is bug 266325 relevant? executables-in-frames generally use http which wouldn't be covered here, plus we *want* it to work since some legitimate sites assume that behavior for their normal download schemes. (The real problem with 266325/284282 is that we preserve the .exe extension on the tmp file. We should give it a bogus extension to prevent accidents in case someone stumbles on the file before we can clean it up, and then rename when the user approves the download.)
Comment 29 User image Manko 2006-04-19 07:03:57 PDT
Of course, bug 266325 is irrelevant, but similar. I have opened bug 334644 to resolve the problem described in 266325.
Comment 30 User image Manko 2006-11-14 02:12:55 PST
Please add P1 because this has a lot of critical dependencies
Comment 31 User image Jesse Ruderman 2006-11-14 09:17:44 PST
I'm changing the severity to "critical" because this bug can be -- and is -- used to perform DoS-like attacks against web users.  (See bug 334426 for a common shock page that abuses this bug.)  I'm also clearing the priority and target milestone fields, which were set before dveditz took the bug and before Last Measure came into existence.  I'm not setting those fields to new values because I'm not the owner.

Is it possible that fixing this is a simple matter of adding a CheckForAbusePoint call, like bug 355482 was? The popup blocking machinery seems to be appropriate here as a way of limiting what user actions can trigger external protocol handlers or previously-unused-protocol dialogs.  I'm not sure that machinery provides a way to limit the number of possibly abusive actions *per click*, but if it doesn't then it should.
Comment 32 User image Manko 2006-11-15 02:17:49 PST
Jesse, I guess that we should separate a codeflow between "click a link" event and <ANYTAG SRC=> reference. It still seems to me that comment #9 should be a proper solution.
Comment 33 User image Manko 2007-08-15 22:24:05 PDT
Changing summary. An internal-handled protocols returning no data (e.g. mailto: or irc: in Seamonkey) should be also denied in <ANYTAG SRC=>.
Comment 34 User image Dan Mosedale (:dmose) 2007-10-03 21:11:56 PDT
The addition of web-based protocol handlers changes the landscape here a bit: <iframe src="mailto:foo"> could actually be meaningful/useful in some cases.
Comment 35 User image Manko 2007-10-03 23:27:08 PDT
Dan, what cases do you mean?
Comment 36 User image Dan Mosedale (:dmose) 2007-10-04 19:11:36 PDT
Well, instead of writing your own feedback form, as many sites do today, one could imagine using <iframe src=">, since this would open up the compose page in your webmail provider in that iframe.  This case might be particularly useful to ISPs who could guarantee that all their users have access to webmail support this.
Comment 37 User image Jesse Ruderman 2007-10-04 19:14:24 PDT
I don't think we should go out of our way to support <iframe src="mailto:"> for webmail.  It would encourage phishing, and turning off third-party cookies would break it.

If an ISP knows what webmail you use they can just embed it with an http URL.
Comment 38 User image Manko 2007-10-05 01:08:19 PDT
Agreed with Jessy.

If "mailto:" URLs would be handled by webmail in my system, I would prefer click to email link and see a new window/tab rather than compose a message in the iframe, even at trusted site. But at untrusted one?..
Comment 39 User image Dan Mosedale (:dmose) 2007-10-26 10:24:16 PDT
Folks interested in this bug may also be interested in attending the security/design review of the web-based protocol handler: <>.
Comment 40 User image Jeremy Nickurak 2009-06-28 12:54:10 PDT
Ran across another "Last Measure" browser exploit.

Careful opening it. It redirects from google (somehow):
Comment 41 User image Jesse Ruderman 2009-08-13 12:53:38 PDT
*** Bug 379804 has been marked as a duplicate of this bug. ***
Comment 42 User image Jeremy Morton 2009-08-13 13:17:48 PDT
GNAA 'shock site' pages have a habit of seriously abusing this.  I think this
should be a priority, maybe for Firefox 4.  I had 100+ thunderbird e-mail
composition windows opening up.
Comment 43 User image timeless 2010-03-22 13:41:06 PDT
Created attachment 434023 [details] [diff] [review]

this seems to make bug 553609 with noscript blocking Java (and flash) tolerable.

note that there are typically many problems w/ such sites:
1. use of various protocol handlers (this bug)
2. trying to download random file types (some other bug)
3. spawning java/flash applets (other bugs)
4. randomly moving windows around (other bugs, already controllable by a preference)
Comment 44 User image Jesse Ruderman 2011-06-02 13:00:30 PDT
*** Bug 660851 has been marked as a duplicate of this bug. ***
Comment 45 User image O. Atsushi (Torisugari) 2012-04-13 04:16:10 PDT
This bug is waiting for something? The patch does not seem checked in.
Comment 46 User image timeless 2015-06-16 07:13:06 PDT
Torisugari, samuel: assuming it still applies (someone should talk to the try-server), it just needs someone to land it.

When this patch received review, I was working for a vendor that used a competing layout engine, so I was generally avoiding bugzilla and certainly not touching Gecko. That is no longer the case.
Comment 47 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2015-06-16 13:12:22 PDT
Given that the review is 5 years old at this point, it'd probably be proper to get a new review though. (Not from me, I don't know this code well enough, nor am I a peer)
Comment 48 User image Patrick McManus [:mcmanus] 2015-12-14 14:36:47 PST
*** Bug 213280 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.