Open Bug 1422860 Opened 7 years ago Updated 5 years ago

Privacy Issue: Replying to or forwarding an HTML e-mail with external content (e.g. images), and clicking on it, may load this content without user notification - take 2

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

People

(Reporter: jorgk-bmo, Unassigned)

References

Details

(Keywords: privacy, sec-low) 

+++ This bug was initially created as a clone of Bug #1409458 +++
In bug 1409458 we fixed the fact that replying/forwarding would load a blocked image although it wasn't shown.

Here we'll address the problem that a single click will also load the image. A double-click will of course load the image since it opens the properties dialogue.

I guess we can track this down with more debugging. Dan, you would be able to assist us here?

=== Original report ===

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171003101344

Steps to reproduce:

In the scope of academic research in cooperation with FH Münster and Ruhr-University Bochum, we discovered a bypass for active content blocking. An example for active content in emails are images in HTML emails that can either be embedded into the email or loaded from the displaying application. This active content can be used to track users as the sender can detect if and when images are loaded. For this reason, Thunderbird blocks active content per default and asks the user if the content should be displayed.

A victim may receive an HTML e-mail with following content:
<html>
   <body>
    <p>Please forward this email to Max Müller!</p>
       <img src=“http://attacker.domain/image.png” />
   </body>
</html>

The user replies to or forwards this email. If the user clicks on the image-pane of the img-tag, an HTTP-request is send immediately to the foreign server. 


Actual results:

An HTTP-request is send immediately to the foreign server. This happens although the user never agreed to load any active content.


Expected results:

The expected behavior of Thunderbird is to ask the user with a yellow bar, if external contents shall be loaded. Always notify the user before the application tries to request any external sources.
Flags: needinfo?(dan-bugzilla)

Should we look at this one day?

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(kaie)
Flags: needinfo?(dan-bugzilla)

Before we can fix it, we need a decision how it should be fixed. Is that already decided?

Flags: needinfo?(kaie)

From comment #0: Here we'll address the problem that a single click will also load the image.

No analysis done, I guess we need to see what happens on click.

If I disable GetObjectForProperties this don't happen, so that's a start for tracking it down.
But all in all, not a very important problem I think.

Flags: needinfo?(mkmelin+mozilla)
Summary: Privacy Issue: Replying to or forwarding an HTML e-mail with external content (e.g. images), may load this content without user notification - take 2 → Privacy Issue: Replying to or forwarding an HTML e-mail with external content (e.g. images), and clicking on it, may load this content without user notification - take 2

Am I understanding this bug right that the user must reply to the email, and then, in the reply, click on the image? If that causes a load of the image, I'm not even sure that is a bug. The click makes the difference for me.

Yes, that's correct. I think it's clearly a bug — a single click, which is easy to do accidentally while you're replying to a message, shouldn't cost you your privacy — but it's considerably less serious than the other bug we fixed, where simply pressing Reply would do so.

(I think it's more debatable whether a double-click on an unloaded image, which opens the properties dialog, should load the image. I'm not sure the presence of the preview area necessarily means it needs to do so, but regardless, a double-click is much less likely to happen accidentally than a single click.)

Usually we say that there must be a clear interaction by the user to trigger network loads. Here, we have not only a reply, but more importantly: a clear interaction by the user with this image element specifically.

You're in the editor, you clicked on the image, so you should be allowed to see the image. In the mail you are sending. Esp. given that the recipient of your mail using Outlook would see it. Of course a load in this case might not be /always/ wanted, but it's fair to say that it's OK.

I strongly disagree. It's about expectation, not interaction. We're talking about a specific privacy feature with a dedicated way of loading images: the button that says to do so. If I'm blocking remote images, I certainly don't expect images to load simply because I pressed Reply, and it was a severe privacy bug when that was happening.

Similarly, simply clicking around in the message you're responding to, when it's not even clear there's an image there, shouldn't trigger a privacy-violating image load either. A user would have no reasonable expectation that that would happen.

Also note that the image isn't even displayed when you click — there's just a connection behind the scenes. So it's violating your privacy without even telling you it's doing so. It's just clearly a bug.

Shouldn't we filter out all image references on reply, to all images that we'd not display when reading this received email?

Well, in a reply you're sending the stuff back to the original sender. They can deal with it, no? Or you mean for WYSIWYG?

For a reply it seems more like a WYSIWYG argument, but it's worth thinking about in the context of forwarding too. If I receive a message with a tracking pixel, which I've blocked, and then I forward the email to someone, I don't want the recipient triggering the tracker either. While it's their email client, it's still my privacy. So I'd be in favor of doing what Kai suggests for both replies and forwards, which would have the side effect of fixing this bug.

(In reply to Kai Engert (:kaie:) from comment #9)

Shouldn't we filter out all image references on reply, to all images that we'd not display when reading this received email?

We're already doing that. This bug here is that, if in that reply window the user still goes on to click on one of those blocked images, then a network request will take place.

Looks like a misunderstanding. Kai is suggesting to remove the images, not just block them.

That would be difficult, and likely unwanted. There are valid cases (like forwarding spam for investigation, or troubleshooting) where you'd like the content to stay intact even if you don't want to ping a server when doing so.

Magnus, could we distinguish between forwarding as inline and as attachment?

When forwarding for investigation, you probably want to forward an unmodified copy, and "forward as attachment" would be the preferred way for that. And when forwarding as attachment, the user wouldn't be able to edit that attachment in the composer window, correct?

I think the reported scenario is about replying, and possibly about forwarding inline. I think that's the scenario where we could strip out all images tags that we're blocking for display.

That's distinguishable, but I'd still rather not mess with the content. The bug here is rather specific so it should be quite fixable once we track it down.

And when forwarding as attachment, the user wouldn't be able to edit that attachment in the composer window, correct?

Indeed. Your suggestion is plausible and also provides better WYSIWYG.

You need to log in before you can comment on or make changes to this bug.