1367716 - Add advanced option to unblock local image files when composing

Status: RESOLVED WONTFIX

(Thunderbird :: Security, defect)

Description

[Mikel Cast]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce:

Composed email messages including image files from local hard drives is now blocked as of version 52.



Actual results:

The message "Thunderbird has blocked a file from loading into this message." appears on screen, so you have to unblock individual images each time you create a new message.


Expected results:

Add an advanced option to the "Thunderbird has blocked a file from loading in this message..." to permanently unblock "file:///"

Comment 1

[Mikel Cast]

This is the new behavior of TB 52+:

https://www.mozilla.org/en-US/thunderbird/52.0/releasenotes/

"When pasting images that reference operating system files into the compose window, the image will now be blocked and a notification will be displayed:
This is to protect users from inadvertently disclosing files."

But an advanced option to disable this behaviour will be desirable.

We use TB to compose email dinamically (through command line), inserting images from local folders.
The "mail.compose.attach_http_images" option do not fix this.

So users need to unblock several images for each composed email.

We're aware of the file disclosure problem, but is preferable to allow us to disable that opcion.

Comment 2

[Mikel Cast]

Could be similar to:
Bug 1366349 and Bug 1362237, but it's not only Add On related.

Comment 3

[Jorg K (CEST = GMT+2)]

Your case is similar to bug 1367141 where people are using the Simple MAPI interface to create HTML e-mail messages with embedded file-based images.

I'll let the Thunderbird module owner answer your request. I could imagine a solution where messages created via the command line interface will automatically get their images converted since I don't believe that this is an attack vector, at least not a very simple one.

(In reply to Mikel Cast from comment #1)
> The "mail.compose.attach_http_images" option do not fix this.
Correct, that's for images from http(s) resources only.

Comment 4

[Jorg K (CEST = GMT+2)]

(In reply to Jorg K (GMT+2) from comment #3)
> I could imagine a
> solution where messages created via the command line interface will
> automatically get their images converted since I don't believe that this is
> an attack vector, at least not a very simple one.
On the other hand, you could change your software to convert file: URLs to data: URLs, which of course would cause huge commands to be sent.

Comment 5

[Magnus Melin [:mkmelin]]

Can you provide an example on what you're doing?

And why not follow comment 4?

Comment 6

[Mikel Cast]

Hi.

We launch TB with the full command line (from within a VB application) with a customized body.
That'is, for example:

C:\>"C:\Program Files\Mozilla Thunderbird\thunderbird.exe" -compose to=[e-mail],subject=This is your offer,format=html,body="<br>Hi [CUSTOMER NAME]<br>An example with [PRICE]<br><img src=file:///C:/CUSTOM/FOLDER/LOGO.PNG><hr>"

(Replace [CUSTOMER NAME] and [PRICE] with real data)

This works, but shows the alert.

Windows has a limit in command prompt length, (maybe this: https://support.microsoft.com/en-us/help/830473/command-prompt-cmd.-exe-command-line-string-limitation)  so we can not convert images to data: URLs

From TB52+ a new parameters exist: "-message=", so we could use a .html file instead of writing the full text into "-body=''" but since we create the email body dynamically (with custom data, as customer name, prices and so...) we can not use a fixed html file.

Thanks in advance.

Comment 7

[Jorg K (CEST = GMT+2)]

Yes, I was going to suggest to write the message to a file, including data: URLs, and then use the -message switch.

C# allows conversion of a file content to base64 in two lines, see bug 1367141 comment #8, so something similar should be possible in VB.

Comment 8

[Mikel Cast]

Yes, it's the same problem that bug 136714,  but we use the command-line instead of MAPI.

Multiple images converted to Base64 and the real body text will overcome the cmd.exe limit.
And using '-message' with a file, with custom text and different images with each new email can be difficult to address. 

If you allow me a suggestion, maybe a
'mail.compose.attach_file_images' (similar to 'mail.compose.attach_http_images') combined with 'mail.compose.attach_file_images.allowedFolderList' where we can specify a parent folder to allow (and automatically allow his subfolders)

Thanks.

Comment 9

[Jorg K (CEST = GMT+2)]

Well, my suggestion would be to automatically accept file-based images if the composition is started from the command line, and even MAPI.

For an attacker to take advantage of this, it would need a lot of convincing of the victim, like:
1) Open a command prompt
2) Paste this command
3) Send the resulting message.

That's like:
1) Open your front door
2) Stand-by while we carry your valuables to our truck ;-)

Comment 10

[Mikel Cast]

Uhmm...

I agree with you about your suggestion...
(for MAPI&CommandLine solution, not about driving the truck   X-)  )

Thanks a lot.

Comment 11

[Magnus Melin [:mkmelin]]

(In reply to Jorg K (GMT+2) from comment #9)
Of course it makes it harder, but unfortunately it's still conceivable. That's why the Firefox dev console makes you jump through hoops for these kind of cases.

Maybe auto-convert when from command line, and the file is in the temp dir. (A script would easily copy it there anyway.)

Comment 12

[Jorg K (CEST = GMT+2)]

Attachment: Add-on that will load files from configurable directory in *new* messages - NOT compatible with TB 68

Add-on that will load files from configurable directory in *new* messages.

New messages can be created via the command line or the Simple MAPI interface. New messages they can only contain a signature image, and that's replaced by TB anyway.

Pattern to match directory name from where to load files can be configured in the preference extensions.loadfiles.pattern, default: .*/temp/.*

Comment 13

[Jorg K (CEST = GMT+2)]

I think the add-on solution is more flexible. So WONTFIX for now.

Comment 14

[Torsten Rendelmann]

The attached downloadable add-on is not anymore compatible with the latest version of TB.
Is it now official? What is the name? I searched various name combinations without a result.

Comment 15

[Jorg K (CEST = GMT+2)]

I provide the add-on. There is a version compatible with TB 68. It's not listed on addons.thunderbird.net.

Comment 16

[Rich Wales]

Jorg, did you plan to provide a TB68-compatible version of your add-on? I can't find it in this bug ticket.

If you can't upload a TB68-compatible version (or provide a link to it), then I would ask you to change the status / resolution so the ticket will stay open.

Comment 17

[Jorg K (CEST = GMT+2)]

See comment #15.

Comment 18

[Rich Wales]

Thanks for your reply, Jorg, but please forgive my confusion, because comment #15 doesn't supply a link to the version of the add-on which I would need for TB 68, and you said this version of the add-on is "not listed at addons.thunderbird.net", and the version you did attach to the ticket (attachment #8872525 [details] in comment #16) is "NOT compatible with TB 68".

Comment 19

[Jorg K (CEST = GMT+2)]

I distribute it privately to very few interested parties.

Comment 20

[Rich Wales]

Could I please get a copy, then? I am using TB 68, and I have a signature (managed by the "Signature Switch" add-on) that contains a picture, and it's a continual annoyance when TB blocks the picture and I need to explicitly allow it each and every time. I'll respect your desire not to make your add-on public and will not redistribute it. Rich Wales, [e-mail]

Comment 21

[Jorg K (CEST = GMT+2)]

For a signature you don't need the add-on. Signature Switch should already handle this correctly. If not, you can convert the picture to a data: URL. The add-on is used by some helpdesk workflows where email is automatically generated with embedded images, either via MAPI or a script.

Comment 22

[Rich Wales]

Thanks. I converted the picture in my signature to a data: URL, and the blocked image problem is gone for me now.

Comment 23

[Jorg K (CEST = GMT+2)]

Right. In the meantime I tried Signature Switch with an image from a file: URL. In fact, that doesn't work. We could contact the author. I've assisted him especially with this part months/years ago. All my signatures include images from http(s): URLs to avoid shipping out the same picture over and over.