[URL] Disable external and returning no data protocol handlers in all cases, excluding <A HREF=>

VERIFIED FIXED in Firefox 66

Status

()

defect
VERIFIED FIXED
17 years ago
3 months ago

People

(Reporter: sinchi, Assigned: baku)

Tracking

(Depends on 1 bug, Blocks 2 bugs, {privacy, sec-want, site-compat})

Trunk
mozilla66
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0PR -

Firefox Tracking Flags

(firefox66 verified)

Details

(Whiteboard: [sg:want][probing][proto][adv-main66-] See bug 173010 for whitelisting protocols)

Attachments

(3 attachments, 2 obsolete attachments)

Reporter

Description

17 years ago
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
problem.

Marking severity critical according to 163648.
Reporter

Updated

17 years ago
Blocks: 163648
Reporter

Comment 1

17 years ago
Another way to exploit URL with external protocols might be using Javascript.
Therefore, we must disaple external protocols in JS operators:
window.open()
location.href=
location.replace()
etc.
Reporter

Updated

17 years ago
Summary: [RFE] Disable external protocol handlers in all cases, excluding <A HREF=> → [URL] Disable external protocol handlers in all cases, excluding <A HREF=>

Comment 2

17 years ago
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.
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.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Severity: critical → enhancement
Reporter

Comment 4

17 years ago
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...
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Reporter

Comment 6

17 years ago
Changing severity from enhancemet to normal - it isn't enhancement anyway.
Severity: enhancement → normal
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.
Assignee: new-network-bugs → darin
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 172498 has been marked as a duplicate of this bug. ***
Reporter

Comment 9

17 years ago
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 |
+-----------------------+    +-------------------------------------+
                   |               |
                   +---------------+
                          |
                          V
            /------------------------------\
           /                                \
  +--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 |
+-----------------------+    +-------------------------------------+
                   |               |
                   +---------------+
                          |
                          V
            /------------------------------\
           /                                \
  +--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

17 years ago
this sounds like 1.2 fodder, no?
Target Milestone: --- → mozilla1.2beta
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.
Reporter

Updated

17 years ago
Blocks: 172498

Comment 12

17 years ago
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.
Target Milestone: mozilla1.2beta → mozilla1.3alpha

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P5

Comment 13

17 years ago
cc'ing bzbarsky since he's done some recent work w/ the unknown protocol handler.
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

17 years ago
-> future (if someone wants to own this, please let me know!)
Target Milestone: mozilla1.3alpha → Future

Comment 16

16 years ago
-> docshell per bz's comment.
Assignee: darin → adamlock
Status: ASSIGNED → NEW
Component: Networking → Embedding: Docshell
QA Contact: benc → adamlock
Docshell can't throttle <img> loads.  We need a more general solution.

Comment 18

15 years ago
*** Bug 243503 has been marked as a duplicate of this bug. ***
*** Bug 244205 has been marked as a duplicate of this bug. ***
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).
Depends on: 229168

Comment 21

15 years ago
Requesting review for 1.0
Flags: blocking-aviary1.0RC1?
Reporter

Comment 22

15 years ago
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.
Blocks: 229168
No longer depends on: 229168
Flags: blocking1.8a2?
Reporter

Comment 23

15 years ago
Oh, sorry, logically i'm right, but bug 229168 have a patch to do this. Begging
your pardons.
No longer blocks: 229168
Depends on: 229168

Comment 24

15 years ago
Why not add a whitelist for external handlers, similar to the cookie 
whitelist? The prompting could be similar too... For example: 
 
The site www.blah.com 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

15 years ago
Whitelist is bug 173010.
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.
Assignee: adamlock → dveditz
Depends on: 173010
Whiteboard: This is not the bug you want--see bug 173010
No longer depends on: 173010
Depends on: 173010
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1-

Updated

15 years ago
Flags: blocking1.8a2?

Updated

13 years ago
Blocks: 334426

Comment 27

13 years ago
See also bug 334426 (especially comments 2 and 3) and bug 266325.
(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.)
Reporter

Comment 29

13 years ago
Of course, bug 266325 is irrelevant, but similar. I have opened bug 334644 to resolve the problem described in 266325.
No longer blocks: 181860
No longer blocks: 213280
Whiteboard: This is not the bug you want--see bug 173010 → [sg:want]This is not the bug you want--see bug 173010
Reporter

Comment 30

13 years ago
Please add P1 because this has a lot of critical dependencies
Blocks: 213280, 356638

Comment 31

13 years ago
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.
Severity: enhancement → critical
Priority: P5 → --
Whiteboard: [sg:want]This is not the bug you want--see bug 173010 → [sg:want] See bug 173010 for whitelisting protocols
Target Milestone: Future → ---
Reporter

Comment 32

13 years ago
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.
Reporter

Comment 33

12 years ago
Changing summary. An internal-handled protocols returning no data (e.g. mailto: or irc: in Seamonkey) should be also denied in <ANYTAG SRC=>.
Summary: [URL] Disable external protocol handlers in all cases, excluding <A HREF=> → [URL] Disable external and returning no data protocol handlers in all cases, excluding <A HREF=>
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.
Whiteboard: [sg:want] See bug 173010 for whitelisting protocols → [sg:want] [proto] See bug 173010 for whitelisting protocols
Reporter

Comment 35

12 years ago
Dan, what cases do you mean?
Well, instead of writing your own feedback form, as many sites do today, one could imagine using <iframe src="mailto:feedback@example.com>, 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

12 years ago
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.
Reporter

Comment 38

12 years ago
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?..
Folks interested in this bug may also be interested in attending the security/design review of the web-based protocol handler: <http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/d7e55195eafea8cc/693cd7bc73167aea#693cd7bc73167aea>.
QA Contact: adamlock → docshell
Assignee: dveditz → nobody

Updated

10 years ago
Duplicate of this bug: 379804

Updated

10 years ago
Depends on: 379803, 379819

Comment 42

10 years ago
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.

Updated

9 years ago
Blocks: eviltraps

Comment 43

9 years ago
Posted patch draftSplinter 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)
Assignee: nobody → timeless
Status: NEW → ASSIGNED
Attachment #434023 - Flags: review?(cbiesinger)

Updated

8 years ago
Duplicate of this bug: 660851

Updated

8 years ago
Keywords: privacy
Whiteboard: [sg:want] [proto] See bug 173010 for whitelisting protocols → [sg:want][fingerprinting][probing][proto] See bug 173010 for whitelisting protocols
Attachment #434023 - Flags: review?(cbiesinger) → review+
This bug is waiting for something? The patch does not seem checked in.

Updated

5 years ago
Flags: needinfo?(timeless)

Comment 46

4 years ago
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.
Flags: needinfo?(timeless)
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)
Duplicate of this bug: 213280
See Also: → 1305177

Updated

2 years ago
See Also: → 331334
Duplicate of this bug: 334426

Comment 50

10 months ago
This is not actually fingerprinting. Fingerprinting external protocols is Bug 680300 - this is about the DOS capability of auto-triggering them to be launched.
Whiteboard: [sg:want][fingerprinting][probing][proto] See bug 173010 for whitelisting protocols → [sg:want][probing][proto] See bug 173010 for whitelisting protocols

Updated

7 months ago
No longer blocks: uplift_tor_fingerprinting
Assignee

Comment 51

7 months ago
Posted patch patch updated (obsolete) — Splinter Review
This patch blocks the opening of external-protocol URLs if the loading has been flagged as LOAD_DOCUMENT_URI: documents cannot be handled by external resources.
Attachment #9026700 - Flags: review?(bugs)
Assignee

Comment 52

7 months ago
Comment on attachment 9026700 [details] [diff] [review]
patch updated

I have a better approach than this.
Attachment #9026700 - Attachment is obsolete: true
Attachment #9026700 - Flags: review?(bugs)
Assignee

Comment 53

7 months ago
Attachment #9026737 - Flags: review?(bugs)
Assignee

Comment 54

7 months ago
Note that we already don't allow loading external protocol URLs in <img> and <script> elements.
Comment on attachment 9026737 [details] [diff] [review]
iframes should not load non-data URLs

Why we think this is web compatible?
data:text/html,<iframe src="mailto:foobar@example.com"> in some other browsers (Chrome at least) is loaded.
I could easily see some web sites relying on the existing behavior.

Can't r+ without some more data here.
Attachment #9026737 - Flags: review?(bugs) → review-
Assignee

Comment 56

7 months ago
> Why we think this is web compatible?

I don't have an answer here. What I can do, is to add telemetry and count how often iframes are loaded with URI_DOES_NOT_RETURN_DATA urls. Is this OK for you?
Flags: needinfo?(bugs)
That gives at least some data, so yes please :)
But would be good to understand better what other browsers do too.
Flags: needinfo?(bugs)
Assignee

Comment 58

7 months ago
Assignee

Updated

7 months ago
Flags: needinfo?(bugs)

Updated

7 months ago
Flags: needinfo?(bugs)
Attachment #9026928 - Flags: review+
Assignee

Updated

7 months ago
Keywords: leave-open

Comment 59

7 months ago
Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8810195a2a42
Telemetry to count how often iframes load no-data URLs, r=smaug
Assignee

Comment 60

7 months ago
I just landed a telemetry patch. Let's wait 1 or 2 cycles before the next steps.
I see 2 possible approaches:

1. if the number of iframes with no-data URLs is almost 0, we can land my previous patch. See comment 53 and 55.

2. if we need to support iframes with no-data URLs, we can use the popup blocking algorithm, allowing just the first iframe to load and blocking the next ones.
Assignee

Comment 62

7 months ago
I think I can steal this bug.
Assignee: timeless → amarchesini
Reporter

Comment 63

7 months ago
What about no-data <IMG SRC="..." and <SCRIPT SRC="..."?
Assignee

Comment 64

7 months ago
HTMLImageElement and HTMLScriptElement are already ignoring external protocols and no-data URLs.
Reporter

Comment 65

7 months ago
<iframe src="mailto:foobar@example.com"> generates popup mail message window with To, CC, Subject, Body etc fields as described in RFC 6068 indeliberately, which possibly may be easily scammed. I strongly doubt that this opportunity is used by respectable sites.

So, collecting statistics we should take into account the degree of site respectability.

Updated

6 months ago
Severity: critical → normal
Assignee

Comment 67

6 months ago
Attachment #9026737 - Attachment is obsolete: true
Attachment #9026737 - Flags: review?(bugs)
Attachment #9029792 - Flags: review?(bugs)
Comment on attachment 9029792 [details] [diff] [review]
iframes should not load non-data URLs

But please don't land before the next merge.
Attachment #9029792 - Flags: review?(bugs) → review+

Comment 69

6 months ago
Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a5ad58077bd8
iframes should load just URLs able to return data, r=smaug
Assignee

Updated

6 months ago
Keywords: leave-open
Assignee

Updated

6 months ago
Status: ASSIGNED → RESOLVED
Closed: 17 years ago6 months ago
Resolution: --- → FIXED
Assignee

Updated

6 months ago
Duplicate of this bug: 331334
Assignee

Updated

6 months ago
Duplicate of this bug: 1271118
Reporter

Comment 73

6 months ago
17 years... Great thanks for all!
Does this fix bug 670328 too?
Flags: needinfo?(amarchesini)
Assignee

Comment 75

6 months ago
No, it covers just the blocking of no_data_URLs for iframes. You can still do: window.location = mailto:foo.
Flags: needinfo?(amarchesini)
I'm confirming that bug is fixed, starting in Mozilla Firefox Nightly 66.0a1 (2018-12-12), so I'm marking this bug as VERIFIED. Thank you very much! \o/
Status: RESOLVED → VERIFIED
QA Contact: Virtual

Updated

5 months ago
Depends on: 1514547
Whiteboard: [sg:want][probing][proto] See bug 173010 for whitelisting protocols → [sg:want][probing][proto][adv-main66-] See bug 173010 for whitelisting protocols
You need to log in before you can comment on or make changes to this bug.