Jens Müller

Full ack, data exfiltration (via auto-saved drafts) is not an Enigmail issue, but an S/MIME issue. Greedy decryption (via mailto: parameters) should be prevented by Enigmail though. An attacker needs both to successfully exploit this issue. I've set the severity to minor, because it requires a somewhat unrealistic attacker model.

Disable "greedy decryption" (e.g., in mailto: URLs)

Disable "greedy decryption" (e.g., in mailto: URLs)

@Nicki: Can you give an example email that is broken by the fix? I could imagine some (partially encrypted) emails generated by KMail in a certain config that could be affected. @Patrick: Even though it does not matter any more -- in the pre-fix version, an attacker could simply change the order of the MIME parts in malicious-email.eml to completely get rid of the warning message when replying, while -- using CSS tricks -- the encrypted part could still be hidden.

Forgot to attach the PoC email (see attached). Also see initial "Decryption oracle PoC 1: Leaking plaintext through reply/forward" report submitted on 2017-11-21 as https://bugzilla.mozilla.org/show_bug.cgi?id=1419417 I did a quick re-test and could not get rid of the red bar. However, still not convinced if this is the perfect long-term solution :/

Out of curiosity: did TBE-01-005 contain actual MIME-wrapping, with the fist MIME part being HTML, hiding the second (encrypted) MIME part -- or was it a single message: ATTACKER'S_TEXT || PGP_ASCII_ARMOR with the decrypted text still being shown? Of course, it's up to the devs to judge if a warning is good enough.

Please find attached a screenshot which depicts the issue. There is a warning in the reply in current TB-versions but I doubt it may be enough.

Leak encrypted emails by replying to benign looking mails