Closed Bug 181860 Opened 22 years ago Closed 18 years ago

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

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha8

People

(Reporter: lambin, Assigned: sicking)

References

(
URL
)

Details

(Keywords: fixed1.8.1, verified1.8.0.5, Whiteboard: [sg:low dos])

Attachments

(2 files, 1 obsolete file)

Patch v2
(deleted), patch
Details | Diff | Splinter Review
branch patch
(deleted), patch
sicking
: approval1.8.0.5+
mtschrep
: approval1.8.1+
Details | Diff | Splinter Review 
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.
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
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). 
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? 
*** Bug 190171 has been marked as a duplicate of this bug. ***
-> Imagelib
Assignee: asa → jdunn
Component: Browser-General → ImageLib
QA Contact: asa → tpreston
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.
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.
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
Flags: blocking1.8a2? → blocking1.8a2-
*** Bug 253959 has been marked as a duplicate of this bug. ***
See also bug 167475 and bug 173010.
*** Bug 273986 has been marked as a duplicate of this bug. ***
*** Bug 275937 has been marked as a duplicate of this bug. ***
*** Bug 299487 has been marked as a duplicate of this bug. ***
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?
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
*** 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
*** Bug 338408 has been marked as a duplicate of this bug. ***
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
Marking blocking for 1.8.0.5, jonas is working on the patch.
Flags: blocking1.8.0.5? → blocking1.8.0.5+
Flags: blocking1.8.1? → blocking1.8.1+
Attached patch Patch v1 (obsolete) (deleted) — — Splinter Review 
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 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+
Attached patch Patch v2 (deleted) — — Splinter Review 
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
Attached patch branch patch (deleted) — — Splinter Review 
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?
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)]
Whiteboard: [sg:low dos] [checkin needed (1.8 branch)] → [sg:low dos]
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
(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.
This caused the regression in bug 346167
No longer depends on: 346720
Flags: blocking1.9a1? → blocking1.9+
Flags: blocking1.9a1+
(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.
Does this patch bug 167475 fully or only partially?
only partially
Flags: blocking1.9a1+
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
Closed: 18 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.
QA Contact: imagelib
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: