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.
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. ***
not necessary for 1.3beta, but we'd consider it for 1.3final
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?
*** Bug 253959 has been marked as a duplicate of this bug. ***
*** 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).
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.
11 years ago
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. ***
*** Bug 338408 has been marked as a duplicate of this bug. ***
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.
Marking blocking for 18.104.22.168, jonas is working on the patch.
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 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
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.
Created attachment 227115 [details] [diff] [review] branch patch This is the branch version of the same patch
Leaving this bug open to handle the case when a page does <iframe src="mailto:..."> or |document.location = "mailto:..."|
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?
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.
11 years ago
v.fixed on 1.8.0 branch with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:22.214.171.124) Gecko/20060706 Firefox/126.96.36.199, the mailto: links in the URL do not launch mail compose windows (as expected with Jonas's branch patch).
(In reply to comment #30) > Created an attachment (id=227108)  > 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.
11 years ago
This caused the regression in bug 346167
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:188.8.131.52) Gecko/20060728 Firefox/184.108.40.206 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 220.127.116.11)? 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?
Lets close this since it's mostly fixed. I opened bug 379804 on the remaining issue.
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).
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:email@example.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.