181860 - Mozilla interprets mailto: and other malformed URLs in IMG SRC tag

Status: RESOLVED FIXED

Description

[Cyril Lambin]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: Build ID 2002091014

When opening this page - that I found on the net and reproduced on my site -, 
Mozilla opens the default mail app (in my case, Outlook Express) as much time 
as there's mailto: URLs in IMG tags. It also opens telnet session with Windows' 
default telnet client.

Reproducible: Always

Steps to Reproduce:
1. Open the task manager
2. Open the page in Mozilla
3. Try to kill Mozilla

Actual Results:  
Fortunately I could kill Mozilla. I guess that on slower computers with less 
stable OS (I run WinXP on an Athlon XP 1900+), the computer might have crashed 
or freezed.

Expected Results:  
In tags which only need to retrieve data (like IMG), Mozilla should ignore 
mailto: URLs and forbid calls to external app.

Comment 1

[Kari Hurtta]

I have no external applications defined for mailto, but
news: in img URL causes mozilla to ask that should it subscibe...

This is 

Mozilla 1.2b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016

Also with

Mozilla 1.3a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021123

Changing OS: Window XP -> All

I do not know what behauviour should be, but perhaps mozilla should
defend itself better. So marking NEW.

/ Kari H.

Comment 2

[Kevin Lacquement]

Is there some way to determine whether a protocol is capable of delivering 
data non-interactively?  For example, http, ftp, chrome, and file would show 
true, while mailto, news, and any unknown protocols would show false.  This 
could be used before attempting to download embedded content (scripts, 
applets, images, etc). 

Comment 3

[Kevin Lacquement]

It looks like the easiest way to implement comment 2 is to add an attribute to  
nsIProtocolHandler.  What rules are there regarding editing interfaces that 
are marked as FROZEN? 

Comment 4

[Jo Hermans]

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

Comment 5

[Matthias Versen [:Matti]]

-> Imagelib

Comment 6

[Christopher Hoess (gone)]

Be very careful if you're going to try to whitelist protocols; it's easy to
overlook stuff. (data: for instance, perhaps the javascript: pseudo-protocol?)

Comment 7

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

not necessary for 1.3beta, but we'd consider it for 1.3final

Comment 8

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

Well, loading the page in the URL field here does not open the mail client for
me. (recent cvs trunk, linux)

bz: Was this possibly fixed by one of your image loading fixes?

Comment 9

[Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-)]

Unlikely....  None of that should have changed with my patch.

Comment 10

[Marc Boon]

HOLY COW!!!
It sure does open several hyperterminal windows, fires news subscribtion dialogs
and tries to do a lot more before I kill it. Maybe it's wise to substitute the
URL above to a more friendly URL demonstrating this unwanted behaviour?

How about this: http://karma-multimedia.nl/bug181860.html

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827

Comment 11

[Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-)]

darin, what do you think of changing nsIProtocolHandler to have a flag for this
purpose, per comment 3?  That does seem like the best approach...

Incidentally, we should not be going out to the OS at all for such loads; I'll
have to look at how that happens once we fix our internal handlers (like
mailto:) to do the right thing.

Comment 12

[Ben Basson]

Another instance at http://www.strangeworld.org/
This kind of stuff should not be allowed... Nominating for 1.8a2 blocker, since
there probably isn't a chance in hell of this being in for 1.7, right?

Comment 13

[Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-)]

The patch in bug 229168 sets up the infrastructure to do this.

Comment 14

[Brent Garber]

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

Comment 15

[Hama]

See also bug 167475 and bug 173010.

Comment 16

[Jesse Ruderman]

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

Comment 17

[Bill Mason]

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

Comment 18

[David Baron :dbaron: ⌚️UTC-7]

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

Comment 19

[Justin Kerk]

I'd like to get this on the radar again, this seems to be a well-known "browser crusher" technique for malicious users in Japanese forums, see http://ja.wikipedia.org/wiki/%E3%83%96%E3%83%A9%E3%82%AF%E3%83%A9#mailto_.E3.82.B9.E3.83.88.E3.83.BC.E3.83.A0 (which describes it as "Mailto Storm"). Another example of an exploit in the wild is http://www.geocities.jp/zxcop0234/ (which you shouldn't click on if unprepared).

Comment 20

[Brent Garber]

On a somewhat related, you can do the same malicious behavior with iframes and mailto: or news:

Comment 21

[Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-)]

Yes, we know.  Note that this depends on bug 229168.

Comment 22

[cignangulo]

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

Comment 23

[:Gavin Sharp [email: [e-mail]]]

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

Comment 24

[Phil Ringnalda (:philor)]

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

Comment 25

[Bob Clary [:bc:]]

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

Comment 26

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I can whip up a patch that is simply based on a blacklist, which I think is the best we can do without chaning any APIs.

Comment 27

[Jay Patel [:jay]]

Marking blocking for 1.8.0.5, jonas is working on the patch.

Comment 28

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Created attachment 227059 [details] [diff] [review]
Patch v1

This patch improves the current situation by making it impossible to put mailto or similar links in <img src="">, <script src=""> etc. I did not manage to block things like <iframe src=""> or |document.location = ...|, that would require changes to nsIContentPolicy.idl. I think we should do that, but not for the 1.8.0 branch (which is what i'm targeting right now).

Comment 29

[Darin Fisher]

Comment on attachment 227059 [details] [diff] [review]
Patch v1

Looks good to me.

A couple recommendations:

QI to nsIExternalProtocolHandler is a cheaper way of testing if the protocol handler returned by GetProtocolHandler is the external protocol handler.  There is similar code here:
http://lxr.mozilla.org/mozilla/source/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp#398

Also, I don't think there is any need to remove category entries.  It's just extra code that isn't ever used.

r+sr=darin

Comment 30

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Created attachment 227108 [details] [diff] [review]
Patch v2

QI to check for the external handler. Left the category stuff though to stay on the safe side on branch.

Comment 31

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Created attachment 227115 [details] [diff] [review]
branch patch

This is the branch version of the same patch

Comment 32

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Leaving this bug open to handle the case when a page does <iframe src="mailto:..."> or |document.location = "mailto:..."|

Comment 33

[Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-)]

So.... that patch doesn't work for non-external protocols that open up random stuff (eg. mailto: in seamonkey).  It's a start, I suppose, but on trunk we should really be using a protocol handler flag like in bug 229168...  I guess we can do that there.

Comment 34

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yes, we should have a better solution for trunk, that's why i'm not marking this bug as FIXED.

Comment 35

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

Not all Geckos necessarily have FTP support. Does Thunderbird?

Comment 36

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

This should land on the branch ASAP as we work up a better solution for trunk. Please add fixed1.8.1 keyword when it's done.

Comment 37

[Jay Patel [:jay]]

v.fixed on 1.8.0 branch with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.5) Gecko/20060706 Firefox/1.5.0.5, the mailto: links in the URL do not launch mail compose windows (as expected with Jonas's branch patch).  

Comment 38

[Michael Ventnor]

(In reply to comment #30)
> Created an attachment (id=227108) [edit]
> Patch v2
> 
> QI to check for the external handler. Left the category stuff though to stay on
> the safe side on branch.
> 

Should resource:// be included in the list of allowed protocols?

Comment 39

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The list of protocols is just a fast-path for schemes that are commonly used and known to be available. I guess resource could be added, but I'm not sure if it matters.

Comment 40

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This caused the regression in bug 346167

Comment 41

[g manca]

(In reply to comment #40)
> This caused the regression in bug 346167
> 

Hi 

sorry I have just downloaded mozilla firefox 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

on my scientific linux machine and the mms application stil does
not work...
Any clue ?
thanks giulia 

Comment 42

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Did it work in any other 1.5.0.x release (like 1.5.0.4)? If not the site is probably incompatible with firefox for some other reason unrelated to this bug.

Comment 43

[Manko]

Does this patch bug 167475 fully or only partially?

Comment 44

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

only partially

Comment 45

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Lets close this since it's mostly fixed. I opened bug 379804 on the remaining issue.

Comment 46

[Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-)]

Um... do we have a bug on not using a protocol list here?  That was OK for branch, but on trunk we should be using protocol flags.  In my opinion.

Comment 47

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The list was just an optimization, which I think is worth keeping no matter what. The real check is the QI to nsIExternalProtocolHandler, is that something that we should change on trunk?

Comment 48

[Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-)]

Yes.  The patch, as written, does not block mailto: in all Gecko consumers, for example (Seamonkey comes to mind here).  It doesn't block extension-implemented data-less protocols that might open windows.  And so on.

The right way to fix this on trunk, imho, would be to have a protocol handler flag for "does not return data" and set that protocol flag on all the relevant protocols (which might just be mailto: and the external protocol in Gecko, but it would give extension authors the chance to make their protocols play nice).

Comment 49

[Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-)]

Ryan Jones filed bug 379819 on the remaining trunk work.

Comment 50

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

Why did you not include TYPE_SUBDOCUMENT in the list? Wouldn't that have helped for iframes?

Comment 51

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

It would also have broken <base target="inner"><a href="mailto:[e-mail]">

basically there is no way to tell the difference between links targeted at an iframe, from iframes src'es

Comment 52

[Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-)]

Not in content policy. But we can add checks for this in the frame loader, since targeted links don't use that code.  Of course malicious sites could then do the targeted thing.. but we're not really trying to protect against malice here.