1246324 - Carefully crafted spam forcing Thunderbird to display a remote/tracking image

Status: RESOLVED WORKSFORME

(Thunderbird :: Security, defect)

Description

[skovac]

Attachment: seospams.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20160120213330

Steps to reproduce:

Receive an e-mail message* in the Junk folder and open it in order to check whether it was a false positive, without allowing the display of (remote) images at any time. 
*Please find attached an archive of 3 such messages; I've opened the one named "CMS..." , using Thunderbird 38.5.1 (Mac version).


Actual results:

A footer image showed up despite not being allowed and a follow-up e-mail was nearly instantly generated and received, this time in INBOX (apparently from another sender, although I strongly suspect it all has the same origin). Since then I have continued to receive new messages from the original sender every two days, with one main differentiating element, located on line 207 of the original (CMS...) spam (in the first img tag after the footer, wrapped in an <a href...> pointing to the software used): "cid:ff4cfb9e5ac5bca1=
ab22fd36d0682b5e".
Furthermore, the subsequent messages include weird "<o:OfficeDocumentSettings>
<o:AllowPNG />", respectively "<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves />
<w:TrackFormatting />
<w:PunctuationKerning />
<w:ValidateAgainstSchemas />
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>" tags, which weren't present in the first occurrence of the spam.
Didn't open those as I don't have a sandboxed Thunderbird handy to try it out. Nonetheless, those additional tags seem to be designed for the same purpose: forcing the e-mail client to display a remote/tracking e-mail "signature" image.
In all three cases, the messages end with what seems to be a base64-encoded image.
It is not clear however how this base64 image alone would trigger a notification to the spammers' server. Nevertheless it does, probably in combination with the 2nd img tag, followed by a reference to the server in question (64.71.162.68), at lines 210 - 211 of the original ("CMS...") spam.


Expected results:

Be able to check for false positives in the Junk folder without triggering the display of images (be it base64 or not), even less of remote content (be it images or something else and possibly less innocuous, although even images can embed malicious code...).

Comment 1

[skovac]

I agree that the security (without emphasising on privacy) impact is relatively low for this bug per se, although in combination with something in the lines of https://blog.mozilla.org/security/2012/02/17/mozilla-releases-to-address-cve-2011-3026/, it could become really dangerous (not only to privacy). There is a problem also in terms of confidence into Thunderbird as an efficient safeguard against such tracking techniques. I think that displaying only the text of messages contained in the Junk folder (vs rendering HTML) by default would be a reasonable compromise for most users. An option for that should be given at least. In the meantime, I am afraid I will have to switch back to plaintext for all messages by default.

Comment 2

[Daniel Veditz [:dveditz]]

(In reply to skovac from comment #0)
> Receive an e-mail message* in the Junk folder and open it in order to check
> whether it was a false positive, without allowing the display of (remote)
> images at any time. 

It's not clear to me that "remote" images were loaded. "cid:" are "content-id" links that reference part of the mail, in this case an in-line (attached) image. If you saw any network traffic are you sure it wasn't to the IMAP server to download chunks it didn't get the first time? Although technically the imap server is "remote" we don't consider that a remote image because it could have all been downloaded in one chunk, and we don't consider your mail server to be hostile (for this purpose, anyway).

> Be able to check for false positives in the Junk folder without triggering
> the display of images (be it base64 or not), even less of remote content (be
> it images or something else and possibly less innocuous, although even
> images can embed malicious code...).

That's a reasonable, but different, request. We do have the "plain text view" feature, but it would be nice to have an easy way to disable images in otherwise HTML mail. It's fairly common for spam to include in-line images because they know most mail clients block remote images now.

I'm going to go ahead and close this "worksforme" since the connection I see is just to the email server, but if you can find a mail that makes a connection elsewhere (especially if you have a network log) please mail [e-mail] and we can reopen this bug. For your other, reasonable request to suppress images I believe we have requests on file already, but if we don't it would be better/clearer to file a new bug with that request stated right up front rather than try to carry on in this hidden bug.