Closed Bug 243306 Opened 20 years ago Closed 19 years ago

"Do not load remote images in Mail & Newsgroup messages" not reliable

Categories

(MailNews Core :: Security, defect)

Product:
MailNews Core
Component:
Security
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: ch.ey, Assigned: sspitzer)

References

Details

(Keywords: privacy, Whiteboard: [sg:privacy])

Attachments

(2 files)

mbox file with 3 example messages
5.29 KB, text/plain
Details
Example of TB mailbox with RSS "emails"
11.65 KB, text/plain
Details 
Using iframes, sender of html messages are able to get Mozilla into loading
remote images.

Ok, one could suggest to use Simple HTML to view messages. But I strongly
encourage that an option "don't load remote images" should work reliable without
any "but you should additionally ...".
Otherwise the user would have a wrong impression of security.

Interesting is, that images in documents loaded in an iframe are blocked when
the option is checked. But images referenced by code like <iframe
src=http://domain.tld/image.jpg> aren't blocked.

I'll attach example messages to illustrate what's possible with an iframe.
First message shows a
  <iframe src=image
case. The second too but the iframe is hidden.
Third message loads a remote document that contains an image.
Ah right, only searched in MailNews.
While I'd say bug 230274 is a dupe to bug 28327.
*** Bug 244586 has been marked as a duplicate of this bug. ***
The problem with iframe is serious -- we don't know it's an image until we've
started loading it!

The right solution for iframes is probably to just block all subframe http loads
or something when this pref is set...
note for bz:

for the first two test cases in that mbox file could we fix
http://lxr.mozilla.org/mozilla/source/content/html/document/src/nsImageDocument.cpp#517
and force the imageLoader to check the policy?

the stack for the first two test cases, I think:

>	gklayout.dll!nsImageDocument::CreateSyntheticDocument()  Line 494	C++
 	gklayout.dll!nsImageDocument::SetScriptGlobalObject(nsIScriptGlobalObject *
aScriptGlobalObject=0x03a29818)  Line 286 + 0x14	C++
 	gklayout.dll!DocumentViewerImpl::InitInternal(nsIWidget *
aParentWidget=0x03a33acc, nsIDeviceContext * aDeviceContext=0x039ed238, const
nsRect & aBounds={...}, int aDoCreation=1, int aInPrintPreview=0)  Line 859	C++
 	gklayout.dll!DocumentViewerImpl::Init(nsIWidget * aParentWidget=0x03a33acc,
nsIDeviceContext * aDeviceContext=0x039ed238, const nsRect & aBounds={...}) 
Line 639	C++
 	docshell.dll!nsDocShell::SetupNewViewer(nsIContentViewer *
aNewViewer=0x03a23760)  Line 4809 + 0x48	C++
 	docshell.dll!nsDocShell::Embed(nsIContentViewer * aContentViewer=0x03a23760,
const char * aCommand=0x02512a2d, nsISupports * aExtraInfo=0x00000000)  Line
4135 + 0x17	C++
 	docshell.dll!nsDocShell::CreateContentViewer(const char *
aContentType=0x03a301d8, nsIRequest * request=0x03a2f1b0, nsIStreamListener * *
aContentHandler=0x03a2f6d8)  Line 4547 + 0x20	C++
 	docshell.dll!nsDSURIContentListener::DoContent(const char *
aContentType=0x03a301d8, int aIsContentPreferred=0, nsIRequest *
request=0x03a2f1b0, nsIStreamListener * * aContentHandler=0x03a2f6d8, int *
aAbortProcess=0x0012f684)  Line 109 + 0x21	C++
 	docshell.dll!nsDocumentOpenInfo::TryContentListener(nsIURIContentListener *
aListener=0x03a29170, nsIChannel * aChannel=0x03a2f1b0)  Line 709 + 0x42	C++
 	docshell.dll!nsDocumentOpenInfo::DispatchContent(nsIRequest *
request=0x03a2f1b0, nsISupports * aCtxt=0x00000000)  Line 451 + 0x39	C++
 	docshell.dll!nsDocumentOpenInfo::OnStartRequest(nsIRequest *
request=0x03a2f1b0, nsISupports * aCtxt=0x00000000)  Line 322 + 0x10	C++
 	necko.dll!nsHttpChannel::CallOnStartRequest()  Line 638 + 0x3c	C++
 	necko.dll!nsHttpChannel::OnStartRequest(nsIRequest * request=0x03a2f930,
nsISupports * ctxt=0x00000000)  Line 3476	C++
 	necko.dll!nsInputStreamPump::OnStateStart()  Line 377 + 0x2a	C++
 	necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream *
stream=0x03a30254)  Line 333 + 0xb	C++
 	xpcom.dll!nsInputStreamReadyEvent::EventHandler(PLEvent * plevent=0x03a30464)
 Line 119	C++
 	xpcom.dll!PL_HandleEvent(PLEvent * self=0x03a30464)  Line 673 + 0xa	C
 	xpcom.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00a28ed8)  Line 608
+ 0x9	C
 	xpcom.dll!_md_EventReceiverProc(HWND__ * hwnd=0x00250848, unsigned int
uMsg=49603, unsigned int wParam=0, long lParam=10653400)  Line 1414 + 0x9	C
 	user32.dll!77d43a50() 	
 	user32.dll!77d43b1f() 	
 	user32.dll!77d43d79() 	
 	ntdll.dll!77f944a8() 	
 	user32.dll!77d43fd4() 	
 	user32.dll!77d43ddf() 	
 	gkwidget.dll!nsAppShell::Run()  Line 135	C++
 	appshell.dll!nsAppShellService::Run()  Line 524	C++
 	mozilla.exe!main1(int argc=1, char * * argv=0x002a57b8, nsISupports *
nativeApp=0x009d2430)  Line 1303 + 0x20	C++
 	mozilla.exe!main(int argc=1, char * * argv=0x002a57b8)  Line 1780 + 0x25	C++
 	mozilla.exe!mainCRTStartup()  Line 398 + 0x11	C
 	kernel32.dll!77e814c7() 	
 	ntdll.dll!77f944a8() 	

the pref is "do not load remote images", maybe it should be "do not load remote
files" or "do not load remote content".

do we have a bug (or did we?) about blocking remote .css files?  I think so, but
I'll query for it.

bz wrote:  "The right solution for iframes is probably to just block all
subframe http loads or something when this pref is set"

I think the problem boils down to wanting to block all remote content, note just
images or iframe documents, to prevent spammers from seeing if I read the message.

Seth, by the time nsImageDocument is created it's too late.  It's created when
we get the HTTP response.  See comment 6 first paragraph, and note the
nsHttpChannel code on your stack.

I agree that what's of interest is blocking all remote content.  Content policy
does get called for remote stylesheets, for subframe loads, and most image
loads.  The few that are not getting content policy calls need to be fixed (and
I'm hoping to have them all stomped by 1.8, but people are of course welcome to
help).
> do we have a bug (or did we?) about blocking remote .css files? 

see bug #28327, ben b's bug about blocking all remote content.
> what's of interest is blocking all remote content

Right. That's what bug 28327 is about, so it's a dup, not?

(I think that the current "don't load remote images" UI option should eventually
be changed into "don't load remote content/files" when bug 28327 is fixed, we
don't need both.)
Yep, I knew this one is a subset of blocking all remote content.
But I thought since bug 28327 is that old at least the blocking of remote
*images* should work flawlessly, i.e. do what the UI promises, this should be filed.

And maybe we should think about having both options where blocking remote images
is automatically included (and disabled in the UI) when choosing to block
everything. I must admit I can't imagine a situation where one wants to only
block images, but I'm by far not omniscient.
(In reply to comment #0)
> Using iframes, sender of html messages are able to get Mozilla into loading
> remote images.

In addition remote images which are used as a background image in a HTML table 
are always loaded, too (at least in thunderbird 0.7.1).

So, if you are trying to fix the iframe-bug, please have a look at that, too.
Also see http://www.theregister.co.uk/2004/07/30/email_privacy/ regarding the
seriour danger of iFRAMES
or simply calling an iframe with no embedded images like

<IfraMe/width=1 height=1
Src=http://microcephale.free.fr/mail/addlog.php?ref=UNIQUE_ID_HERE frameborder=0
STYLE="width: 0; height: 0px; border:0px"></IfraMe>

is invisible and works perfectly.
ability to block ALL kind of remote content thru the privacy settings is a
must-have.
Problem with the iframe can be now more serious.
New Thunderbird 0.8 has RSS accounts. Look, in the default configuration it
loads RSS file and from it creates e-mails, which contains <iframe> with src
obtained from the RSS file (so the loads webpage instead of e-mail).

What it means?

a) huge amount of spamers can be now aware of Mozilla <iframe> problem, because
TB  "is using this bug"
b) fixing this bug can affet Mozilla Thunderbird
Adding sample of TB RSS mailbox as attachment.
I've never been quite sure why this was not a dupe of bug 28327, but since
that's now "fixed" and the <iframe> problem remains on the trunk (though really
fixed in thunderbird) maybe we need this one as a fresh start.
Product: MailNews → Core
Flags: blocking-aviary1.5?
Whiteboard: [sg:fix]
I sent myself an email with

foo <iframe src="http://www.google.com/" width="100" height="100"> baz

and the iframe didn't load until I clicked the "Thunderbird has blocked remote
images" bar.  I'm using Thunderbird version 1.0+ (20050804).  Un-nominating from
blocking Thunderbird 1.5.
Flags: blocking-aviary1.5?
Fixed somewhere along the way, possibly by bug 28327
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: privacy
Resolution: --- → WORKSFORME
Whiteboard: [sg:fix] → [sg:privacy]
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: