1524750 - Thunderbird cannot decode correctly emails containing .eml attachments

Status: RESOLVED WONTFIX

(Thunderbird :: Security, defect)

Description

[chico]

Attachment: Sample Signed and Encrypted Email.eml

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

Steps to reproduce:

1. Send to myself a simple message with some body text and then attach the sample .EML file to the message (which happens to be a signed and encrypted EML).
2. After receiving this email back, it seems that Thunderbird cannot decode correctly the message.
3. Double-clicking the EML file in attachment pane shows up empty.
4. If I view the message source of the attachment, it shows garbage.

Actual results:

Unable to decode emails with .EML as attachments. the attached EML are not decoded correctly (maybe due to new security checks?)

Expected results:

Should be able to read the attached EML files. The previous stable version (Thunderbird 52) did not have this issue.

Comment 1

[Jorg K (CEST = GMT+2)]

All I can think of it the new mail.decrypt_children preference. We introduced that to mitigate Efail and we now only decrypt top level content. Try setting this to true and see what happens.

https://hg.mozilla.org/comm-central/rev/b474dfcfa256b5f5800083d592a8307b430d1303#l1.12

Magnus, looks like the reporter isn't happy with that extra security measure.

Comment 2

[chico]

After Jorg's hint about EFAIL, I could get back the previous behavior in version 52 by setting mailnews.p7m_subparts_external to false in about:config. Thank you!

Comment 3

[Jorg K (CEST = GMT+2)]

Sorry, I gave you the wrong preference name. in comment #1.

Comment 4

[Kai Engert [:KaiE:]]

chico, thanks for your report. The current behavior you see is intended. We have changed the behavior to the current one, in order to fix vulnerabilities which were described as EFAIL. (See https://efail.de/ .)

In the following comment, I will explain why you get the behavior, and I will explain why setting that pref is a bad idea, and I will show you an alternative workaround.

However, your report also shows, that we haven't done a good job at handling EFAIL from the user interface perspective, and that we should probably handle that better, I've filed bug 1576655 to track that.

Comment 5

[Kai Engert [:KaiE:]]

If you set preference mailnews.p7m_subparts_external to false (non-default), then you are vulnerable to certain variations of the EFAIL attackes. I recommend that you keep the preference at the default value.

Modern email is structured like a Matryoshka doll ( https://en.wikipedia.org/wiki/Matryoshka_doll ), it has an outer envelope, and it may contain nested message parts inside it.

An attacker could take the core data of some other encrypted email (encrypted for you), and use it to manually craft a new email, by placing that encrypted part in the middle of an email. If the attacker sends you this crafted email, and if your email client decrypts the middle part, then the attacker could trick you. If you reply to the message, the decrypted part might get sent to the attacker, without you noticing.

In order to prevent this general kind of attack, it has been decided that we'll never decrypt message parts that are somewhere in the middle of another email.

If the outermost layer of the email is an encryption layer, then we'll decrypt it. Otherwise, we intend to simply treat it as an attachment.

In your example, the encrypted part is in a middle layer, and therefore we don't decrypt it.

Here's a workaround:

In the received message, find the attached .eml file, right click, and use "Save As" to save it to a file.
Then, use the menu, select File, Open Saved Message. Select the file that you have saved. The message will be opened in its own, independent message. You should get the decrypted content (if you have the private key to decrypt the attached file), and you should also see the signature status.

I'd like to resolve this bug report as wontfix, because we don't intend to change how the message is displayed for security reasons. Maybe you could CC yourself to bug 1576655. Maybe we can develop a better way to treat such attachments in the future.