Bug 452093 (CVE-2010-0181)

Redirect to mailto:address in linked image opens email editor

RESOLVED FIXED in mozilla1.9.3a2

Status

()

Core
ImageLib
RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: Henry Sudhof, Assigned: bsterne)

Tracking

({verified1.9.1, verified1.9.2})

Trunk
mozilla1.9.3a2
verified1.9.1, verified1.9.2
Points:
---
Bug Flags:
wanted1.9.0.x +

Firefox Tracking Flags

(status1.9.2 .2-fixed, status1.9.1 .9-fixed)

Details

(Whiteboard: [sg:low])

Attachments

(3 attachments, 3 obsolete attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

I was notified by an user ("Reelix") about a weird behavior with img tags. I wasn't able to find a duplicate, so I thought it might be better to file a report here, despite you probably being aware of the issue.

If the request for the image is answered with a response redirecting to a mailto: address, then the default email editor opens.

i.e.
<img src="<page that redirects to mailto:foo@bar>" /> will cause firefox to open the default email application.

or more verbatim:
a t.html
--snip
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<html>
   <head>
      <title>mail test</title>
   </head>
   <body>
  <img src="t.php" />
   </body>
</html>
--snap

Where t.php redirects to mailto:foo@bar.com?subject=Irritating%20popup&body=I%20d
o%20not%20think%20image%20tags%20should%20be%20able%20to%20t
his .

Opens the email editor. I don't think that image tags should be able to open any external applications and/or cause popups.

Thanks for looking into it,
cheers
~H



Reproducible: Always

Steps to Reproduce:
1. write a page with an image tag like <img src="foo.php" />
2. have foo.php redirect to mailto:foo@bar.com (header('location:mailto:foo@bar.com');)
3. View the page 
Actual Results:  
The external email editor opens.

Expected Results:  
Broken image.
(Reporter)

Comment 1

9 years ago
Created attachment 335370 [details]
HTML testcase using tinyurl
(Reporter)

Updated

9 years ago
Version: unspecified → 3.0 Branch

Comment 2

9 years ago
Confirming.  

This definitely looks like something that should be forbidden.  Cc'ing dveditz for his professional opinion.
Status: UNCONFIRMED → NEW
Component: General → File Handling
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → file-handling
Version: 3.0 Branch → Trunk

Comment 3

9 years ago
Confirmed on windows vista and mac:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080903034741 Minefield/3.1b1pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a2pre) Gecko/20080819152019 Minefield/3.1a2pre

sorry for bugspam
(Reporter)

Comment 4

9 years ago
I am very sorry about being a pain, but is there any movement on this?

Cheers,
~H

Comment 5

9 years ago
Created attachment 340966 [details]
Using mailto link in an image

This is a test with a image that has a mailto: link as the source, you can see that there is a broken link in this case.  So, the question is do we want to detect the redirect and show a broken image in this case or not?
(Assignee)

Comment 6

8 years ago
Doesn't look like there's been much movement here (though dveditz didn't get cc'd per comment 2... he's cc'd now).

I'm going to set this as sg:low for now, since this is more of a DoS/annoyance than anything.
Whiteboard: [sg:low]
(Reporter)

Comment 7

8 years ago
I have to say: this is potentially a very bad annoyance. Spammers could use this easily to bypass the popup blocker. Current measures like noscript wouldn't help a bit.
(Reporter)

Comment 8

8 years ago
Sorry for being a pest, but we ("phpBB") keep getting reports about this being used for spam/popups with an increasing frequency.

Cheers,
~H
(Reporter)

Comment 9

7 years ago
Hi,
I'm sorry, but I have  to give this its semi-annual bump. It is by now commonly used in spam entries on forums. 

I am by now tempted to contact the media about the issue. I'm sure that there are many pressing problems, but this renders the popup blocker useless and is developing into a real problem.

Cheers,
all the best,
~H

Comment 10

7 years ago
Confirmed on Ubuntu 9.10 with Firefox 3.5.7 opening Empathy mail client.

Comment 11

7 years ago
[edit]

The Evolution mail client, not Empathy.
(Assignee)

Comment 12

7 years ago
I'm going to take a stab at this.
Assignee: nobody → bsterne
(Assignee)

Comment 13

7 years ago
Created attachment 426017 [details] [diff] [review]
fix
Attachment #426017 - Flags: review?(jst)
Comment on attachment 426017 [details] [diff] [review]
fix

Don't hardcode protocol names. Instead, I think you want to check for the URI_DOES_NOT_RETURN_DATA protocol handler flag. (Something like http://mxr.mozilla.org/mozilla-central/source/parser/htmlparser/src/nsViewSourceHTML.cpp#1074)
Attachment #426017 - Flags: review?(jst) → review-
Or maybe URI_NON_PERSISTABLE is better.
In fact, this should be using the same code as nsNoDataProtocolContentPolicy::ShouldLoad.

Heck, ideally it should be _calling_ that ShouldLoad....  As well as perhaps other content policy methods.  Sadly, content policy doesn't really mesh that well with redirects.
(Assignee)

Comment 17

7 years ago
My first patch copied code from nsNoDataProtocolContentPolicy::ShouldLoad, in fact.  I agree that the ideal fix would be to call that function, but we lack the context we need to do so during the redirect.

Shall we go forward, then, with the patch suggested in comment 14?
> My first patch copied code from nsNoDataProtocolContentPolicy::ShouldLoad

No, it copied _part_ of that code.  The fast-path.  You either need to copy all the code or just copy the non-fast-path part (depending on how performance-critical we think image redirects are).

I'm not entirely convinced that the fast-path is even important in ShouldLoad there, btw.
(Assignee)

Comment 19

7 years ago
Created attachment 426038 [details] [diff] [review]
fix v2
Attachment #426017 - Attachment is obsolete: true
Attachment #426038 - Flags: review?(bzbarsky)
So questions:

1) Why the original URI and not the URI?
2) Does this not leave the issue for stylesheet loads, script loads, etc?
(Assignee)

Comment 21

7 years ago
(In reply to comment #20)
> 1) Why the original URI and not the URI?
I don't have a reason why other originalURI was being used in another check in this function already.  It makes more sense to use URI since that will take into account URI resolution. 

> 2) Does this not leave the issue for stylesheet loads, script loads, etc?
It does leave this problem for those other types of loads.  I think the reason this bug was filed with images in mind is that this is a particular problem for forums and such who allow users to post images, but not necessarily those other types of content.
Ah, I see.  OK, then this is ok for now but we should get a followup bug filed to tag loads that shouldn't permit no-data stuff somehow and just have the global redirect observer enforce this restriction.... or something.
Comment on attachment 426038 [details] [diff] [review]
fix v2

r=me if you use the URI instead of the originalURI.
Attachment #426038 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 24

7 years ago
Created attachment 426047 [details] [diff] [review]
fix v3

Addresses bz's comments.
Attachment #426038 - Attachment is obsolete: true
Attachment #426047 - Flags: review+
(Assignee)

Comment 25

7 years ago
Boris, re: comment 22, there is bug 456957, which is to make Content Policy work with redirects.  Is that sufficient, or shall I open up a follow-up bug to tag loads (channels?) with dont-allow-nodata and have a redirect observer set up to enforce those?
should imagelib really use a DOM error code?
(Assignee)

Comment 27

7 years ago
I have no attachment to that particular error code.  I'm open to other suggestions.
Comment on attachment 426047 [details] [diff] [review]
fix v3

I'd probably just go with NS_ERROR_ABORT, or if you prefer a new error code added to ImageErrors.h.
(Assignee)

Comment 29

7 years ago
Created attachment 426262 [details] [diff] [review]
fix v4

Changed error code.  Carrying forward Boris' r+.
Attachment #426047 - Attachment is obsolete: true
Attachment #426262 - Flags: review+
(Assignee)

Updated

7 years ago
status1.9.1: --- → ?
status1.9.2: --- → ?
status2.0: --- → ?
Keywords: checkin-needed
(Assignee)

Updated

7 years ago
status1.9.1: ? → ---
status1.9.2: ? → ---
status2.0: ? → ---
(Assignee)

Updated

7 years ago
Attachment #426262 - Flags: review?(joe)
Attachment #426262 - Flags: review?(joe) → review+
http://hg.mozilla.org/mozilla-central/rev/c492fb6295d1
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Component: File Handling → ImageLib
Keywords: checkin-needed
OS: Windows Vista → All
QA Contact: file-handling → imagelib
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a2
> there is bug 456957, which is to make Content Policy work with redirects.  Is
> that sufficient,

I'd prefer a separate bug with narrower scope to handle just the no-data thing, I think.
(Assignee)

Comment 32

7 years ago
Filed follow-up bug 545871.
(Assignee)

Updated

7 years ago
Attachment #426262 - Flags: approval1.9.2.2?
Attachment #426262 - Flags: approval1.9.1.9?
Attachment #426262 - Flags: approval1.9.0.19?
Comment on attachment 426262 [details] [diff] [review]
fix v4

a=beltzner for all branches, why aren't there tests?

I bet you'll add some tests. :)
Attachment #426262 - Flags: approval1.9.2.2?
Attachment #426262 - Flags: approval1.9.2.2+
Attachment #426262 - Flags: approval1.9.1.9?
Attachment #426262 - Flags: approval1.9.1.9+
Attachment #426262 - Flags: approval1.9.0.19?
Attachment #426262 - Flags: approval1.9.0.19+

Comment 34

7 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/0c83ead0ce8d
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/644a650d452d
status1.9.1: --- → .9-fixed
status1.9.2: --- → .2-fixed
Comment on attachment 426262 [details] [diff] [review]
fix v4

This missed the deadline.
Attachment #426262 - Flags: approval1.9.0.19+ → approval1.9.0.19-
Verified for 1.9.2 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2pre) Gecko/20100315 Namoroka/3.6.2pre (.NET CLR 3.5.30729) using attached testcase.

Verified for 1.9.1 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9pre) Gecko/20100311 Shiretoko/3.5.9pre (.NET CLR 3.5.30729).
Keywords: verified1.9.1, verified1.9.2
Flags: wanted1.9.0.x+
Alias: CVE-2010-0181

Comment 37

7 years ago
mustlive posted on bugtraq that other browsers are affected http://www.securityfocus.com/archive/1/511327
(Reporter)

Comment 38

7 years ago
I would argue that the report by mustlive is less critical/ of a vulnerability. Posting images is a common feature for "normal" users on blogs, forums etc. The img src vector allowed circumventing the popup blocker and DoS on such sites.
 
By contrast, being able to post an iframe with an arbitrary source is enough for conducting far worse attacks on the site and its visitors - including DoS, but extending to attacks on common plugins, XSS and worse.



Cheers,
~H
Group: core-security
You need to log in before you can comment on or make changes to this bug.