Consider blocking inline images

NEW
Unassigned

Status

Thunderbird
Security
13 years ago
3 months ago

People

(Reporter: Scott MacGregor, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
After talking to dveditz, we might want to consider blocking inline images in mail by default, leveraging our remote image blocker bar to allow users to reload the message with the inline images.

This would be tied to whatever trusted address policy we have for bypassing the blocked inline image check.

Might be tricky to implement this. our remote image blocker is tied to thunderbird's content policy manager which detects the attempt to load the remote image. That code isn't invoked at all for an inline image.

Comment 1

12 years ago
Does it block also the pictures (xxx.jpg) shown in line in the mail?
With the .wmf bug found (and corrected but there may be others), I fear to open this pictures even if the mail seems to come from one of my children : the From: line may be faked.
If I choose in my viewing preferences to show only in "text only" format (not html) and without attachment in line, are all the image blocked and not loaded? Do I have a simple way to show the images on request? e.g. "Bug 172184 Unblock images for a specific message"

Comment 2

12 years ago
I'd like to see this capability, too. Consider the bugs around image processing libraries and crafted images, and/or all the image spam that I'd rather not see.

I don't know how to do it but found that these images usually have an address like 'cid:number'. This could probably be detected during MIME processing. Also, if I could disable HTML display completely so that I'm shown the HTML source of an HTML message, that would solve the problem, too.

Comment 3

12 years ago
I have discovered that if I block remote images in my preferences they are blocked (of course) but if I push the "forward" button the previously blocked images appear : I think this is a bug in the "policy manager" and a breach of security see .wmf bug and virus!
> but if I push the "forward" button the previously blocked images appear

That is not this bug, that's bug 263345 (fixed by bug 330443, should be fixed in the Thunderbird 2 beta 1 just released).
(Reporter)

Comment 5

11 years ago
we made great strides with remote images but didn't get to inline images which don't go through the content policy logic. Let's work on that in the next release.
Target Milestone: Thunderbird2.0 → Thunderbird 3

Updated

11 years ago
Duplicate of this bug: 374696

Updated

11 years ago
OS: Windows XP → All
Hardware: PC → All

Updated

10 years ago
Assignee: mscott → nobody
Duplicate of this bug: 290082

Updated

9 years ago
Duplicate of this bug: 415615

Updated

8 years ago
Duplicate of this bug: 547568

Comment 10

8 years ago
Hello everybody.

In the bug 547568 I show some details of the message body and the strategy they use: one identified image section and a html section linking the image source via the "cid:" of the image section.
This trick makes Thunderbird not to dectect and shows porn images in messages.

Updated

5 years ago
Duplicate of this bug: 934302

Updated

3 years ago
Duplicate of this bug: 1117446

Comment 13

2 years ago
are there other bugs related to this?
Component: General → Security
Flags: needinfo?(mkmelin+mozilla)
Target Milestone: Thunderbird 3 → ---

Comment 14

2 years ago
Not that I know of.
Flags: needinfo?(mkmelin+mozilla)

Updated

2 years ago
Duplicate of this bug: 1314417

Comment 16

2 years ago
I believe we already have this feature; set the pref "mailnews.display.disallow_mime_handlers" to 2 (or greater), and it will block images whether they're inline or not. See here: <https://dxr.mozilla.org/comm-central/source/mailnews/mime/src/mimei.cpp#289>.

To be fair, this isn't the most user-friendly, since you have to 1) set a hidden pref, and 2) go to View -> Message Body As every time you want to switch to seeing images (and then remember to turn it back off!), but the mailnews part works already, and we could simply enhance the usability here if we thought this was valuable.

One possibility would be to have messages marked as junk automatically use simple HTML without images.

Comment 17

2 years ago
(In reply to Jim Porter (:squib) from comment #16)
> One possibility would be to have messages marked as junk automatically use
> simple HTML without images.

I belive we already do that.

Comment 18

2 years ago
Well, we don't for messages in the Junk folder from Gmail. I don't use Thunderbird junk filters, so I'm not sure exactly how they work. Maybe all we need to do is treat all messages in a Junk folder as junk by default?

Comment 19

2 years ago
(In reply to Jim Porter (:squib) from comment #18)
> Well, we don't for messages in the Junk folder from Gmail. I don't use
> Thunderbird junk filters, so I'm not sure exactly how they work. Maybe all
> we need to do is treat all messages in a Junk folder as junk by default?

bug 1273818 is an idea along those lines

Comment 20

2 years ago
From a user perspective, the important thing is an obvious way to set a don't-display-images bit in the entire client by default while still rendering the balance of the HTML - right now the only way to satisfy the first objective is to render all messages as text, and there's no way to render the HTML on a per-message basis.

A clear path to a whitelist manager would also be excellent.

I point all interested parties to my unexpected behavior description in the (duplicate) https://bugzilla.mozilla.org/show_bug.cgi?id=1314417 that got me invited to this thread.  (I'm a web developer of long and comparatively impressive standing who's a tourist around these parts.)

One does not want to be minding his own business in the local coffeeshop, or his open-bay office, or in his living room with his kids, only to discover that some jackhat has dumped uninvited porn stills into his inbox by leveraging the client's RFC 2111 compliance.

Updated

a year ago
Duplicate of this bug: 1321611

Comment 22

3 months ago
Please block inline images that contain bytes within the html.
You need to log in before you can comment on or make changes to this bug.