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)
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha8
People
(Reporter: lambin, Assigned: sicking)
References
()
Details
(Keywords: fixed1.8.1, verified1.8.0.5, Whiteboard: [sg:low dos])
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(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.
Comment 1•22 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•22 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•22 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 5•22 years ago
|
||
-> Imagelib
Assignee: asa → jdunn
Component: Browser-General → ImageLib
QA Contact: asa → tpreston
Updated•22 years ago
|
Flags: blocking1.3b?
Comment 6•22 years ago
|
||
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-
Comment 8•22 years ago
|
||
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 10•21 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
![]() |
||
Comment 11•21 years ago
|
||
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•21 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?
![]() |
||
Comment 13•21 years ago
|
||
The patch in bug 229168 sets up the infrastructure to do this.
Depends on: 229168
Updated•21 years ago
|
Flags: blocking1.8a2? → blocking1.8a2-
Comment 19•19 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•19 years ago
|
||
On a somewhat related, you can do the same malicious behavior with iframes and mailto: or news:
Updated•19 years ago
|
Assignee: jdunn → pavlov
QA Contact: tpreston
Updated•19 years ago
|
Flags: blocking1.8.1?
Flags: blocking1.8.0.5?
Updated•19 years ago
|
Whiteboard: [sg:want]
Assignee | ||
Comment 26•19 years ago
|
||
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•19 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•19 years ago
|
Flags: blocking1.8.1? → blocking1.8.1+
Assignee | ||
Comment 28•19 years ago
|
||
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)
Updated•19 years ago
|
Whiteboard: [sg:want] → [sg:want] need reviews
Comment 29•19 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+
Assignee | ||
Comment 30•19 years ago
|
||
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
Assignee | ||
Comment 31•19 years ago
|
||
This is the branch version of the same patch
Attachment #227115 -
Flags: approval1.8.1?
Attachment #227115 -
Flags: approval1.8.0.5+
Assignee | ||
Comment 32•19 years ago
|
||
Leaving this bug open to handle the case when a page does <iframe src="mailto:..."> or |document.location = "mailto:..."|
Keywords: fixed1.8.0.5
Updated•19 years ago
|
Whiteboard: [sg:want] need reviews → [sg:low dos]
Updated•19 years ago
|
Flags: blocking1.7.14?
Flags: blocking-aviary1.0.9?
![]() |
||
Comment 33•19 years ago
|
||
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.
Assignee | ||
Comment 34•19 years ago
|
||
Yes, we should have a better solution for trunk, that's why i'm not marking this bug as FIXED.
Updated•19 years ago
|
Attachment #227115 -
Flags: approval1.8.1? → approval1.8.1+
Comment 36•19 years ago
|
||
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]
Updated•18 years ago
|
Whiteboard: [sg:low dos] [checkin needed] → [sg:low dos] [checkin needed (1.8 branch)]
Assignee | ||
Updated•18 years ago
|
Keywords: fixed1.8.1
Updated•18 years ago
|
Whiteboard: [sg:low dos] [checkin needed (1.8 branch)] → [sg:low dos]
Comment 37•18 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•18 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?
Assignee | ||
Comment 39•18 years ago
|
||
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.
Updated•18 years ago
|
Flags: blocking1.9a1? → blocking1.9+
![]() |
||
Updated•18 years ago
|
Flags: blocking1.9a1+
Comment 41•18 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
Assignee | ||
Comment 42•18 years ago
|
||
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.
Updated•18 years ago
|
Flags: blocking1.9a1+
Target Milestone: --- → mozilla1.9beta1
Assignee | ||
Comment 45•18 years ago
|
||
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
![]() |
||
Comment 46•18 years ago
|
||
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.
Assignee | ||
Comment 47•18 years ago
|
||
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•18 years ago
|
||
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 50•17 years ago
|
||
Why did you not include TYPE_SUBDOCUMENT in the list? Wouldn't that have helped for iframes?
Assignee | ||
Comment 51•17 years ago
|
||
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
![]() |
||
Comment 52•17 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•