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

RESOLVED FIXED in mozilla1.9alpha8

Status

()

Core
ImageLib
--
critical
RESOLVED FIXED
15 years ago
8 years ago

People

(Reporter: Cyril Lambin, Assigned: sicking)

Tracking

(Blocks: 1 bug, {fixed1.8.1, verified1.8.0.5})

Trunk
mozilla1.9alpha8
x86
All
fixed1.8.1, verified1.8.0.5
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.3b -
blocking1.7.14 ?
blocking-aviary1.0.9 ?
blocking1.8a2 -
blocking1.8.1 +
blocking1.8.0.5 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low dos], URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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

15 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All

Comment 2

15 years ago
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

15 years ago
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

15 years ago
*** Bug 190171 has been marked as a duplicate of this bug. ***
-> Imagelib
Assignee: asa → jdunn
Component: Browser-General → ImageLib
QA Contact: asa → tpreston

Updated

15 years ago
Flags: blocking1.3b?
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?)
not necessary for 1.3beta, but we'd consider it for 1.3final
Flags: blocking1.3b? → blocking1.3b-
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?
Unlikely....  None of that should have changed with my patch.

Comment 10

14 years ago
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
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

13 years ago
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?
Flags: blocking1.8a2?
The patch in bug 229168 sets up the infrastructure to do this.
Depends on: 229168

Updated

13 years ago
Flags: blocking1.8a2? → blocking1.8a2-

Comment 14

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

Comment 15

13 years ago
See also bug 167475 and bug 173010.

Comment 16

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

Comment 17

13 years ago
*** Bug 275937 has been marked as a duplicate of this bug. ***
*** Bug 299487 has been marked as a duplicate of this bug. ***

Comment 19

12 years ago
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).
Flags: blocking1.9a1?

Comment 20

12 years ago
On a somewhat related, you can do the same malicious behavior with iframes and mailto: or news:
Yes, we know.  Note that this depends on bug 229168.
Depends on: 167475
No longer depends on: 167475

Comment 22

11 years ago
*** Bug 337973 has been marked as a duplicate of this bug. ***
*** Bug 338387 has been marked as a duplicate of this bug. ***
*** Bug 296190 has been marked as a duplicate of this bug. ***
Assignee: jdunn → pavlov
QA Contact: tpreston

Comment 25

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

Updated

11 years ago
Flags: blocking1.8.1?
Flags: blocking1.8.0.5?
Blocks: 340442
Whiteboard: [sg:want]
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.
Assignee: pavlov → bugmail

Comment 27

11 years ago
Marking blocking for 1.8.0.5, jonas is working on the patch.
Flags: blocking1.8.0.5? → blocking1.8.0.5+

Updated

11 years ago
Flags: blocking1.8.1? → blocking1.8.1+
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).
Attachment #227059 - Flags: superreview?(bzbarsky)
Attachment #227059 - Flags: review?(bzbarsky)
Whiteboard: [sg:want] → [sg:want] need reviews

Comment 29

11 years ago
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
Attachment #227059 - Flags: superreview?(bzbarsky)
Attachment #227059 - Flags: superreview+
Attachment #227059 - Flags: review?(bzbarsky)
Attachment #227059 - Flags: review+
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.
Attachment #227059 - Attachment is obsolete: true
Created attachment 227115 [details] [diff] [review]
branch patch

This is the branch version of the same patch
Attachment #227115 - Flags: approval1.8.1?
Attachment #227115 - Flags: approval1.8.0.5+
Leaving this bug open to handle the case when a page does <iframe src="mailto:..."> or |document.location = "mailto:..."|
Keywords: fixed1.8.0.5
Whiteboard: [sg:want] need reviews → [sg:low dos]
Blocks: 334426
Flags: blocking1.7.14?
Flags: blocking-aviary1.0.9?
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.
Yes, we should have a better solution for trunk, that's why i'm not marking this bug as FIXED.
Not all Geckos necessarily have FTP support. Does Thunderbird?

Updated

11 years ago
Attachment #227115 - Flags: approval1.8.1? → approval1.8.1+
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.
Whiteboard: [sg:low dos] → [sg:low dos] [checkin needed]
Whiteboard: [sg:low dos] [checkin needed] → [sg:low dos] [checkin needed (1.8 branch)]
Keywords: fixed1.8.1
Whiteboard: [sg:low dos] [checkin needed (1.8 branch)] → [sg:low dos]

Comment 37

11 years ago
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).  
Keywords: fixed1.8.0.5 → verified1.8.0.5

Comment 38

11 years ago
(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?
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.
Depends on: 346167
This caused the regression in bug 346167
Depends on: 346720
No longer depends on: 346720

Updated

11 years ago
Flags: blocking1.9a1? → blocking1.9+
Flags: blocking1.9a1+

Comment 41

11 years ago
(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 
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

11 years ago
Does this patch bug 167475 fully or only partially?
only partially
Flags: blocking1.9a1+

Updated

11 years ago
Depends on: 363235
Target Milestone: --- → mozilla1.9beta1
Lets close this since it's mostly fixed. I opened bug 379804 on the remaining issue.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Flags: blocking1.9+
Resolution: --- → FIXED
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.

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?
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).
Depends on: 379819
Ryan Jones filed bug 379819 on the remaining trunk work.
Why did you not include TYPE_SUBDOCUMENT in the list? Wouldn't that have helped for iframes?
It would also have broken <base target="inner"><a href="mailto:foo@bar.com">

basically there is no way to tell the difference between links targeted at an iframe, from iframes src'es
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.

Updated

8 years ago
QA Contact: imagelib
You need to log in before you can comment on or make changes to this bug.