In the scope of academic research in cooperation with Ruhr-Uni Bochum and FH Münster, Germany we discovered a security issue in Trojitá: An attacker who is in possession of PGP or S/MIME encrypted messages can embed them into a multipart message and re-send them to the intended receiver. When the message is read and decrypted by the receiver, the attacker's content is shown. If the victim replies, the plaintext is leaked to an attacker's email address. The root cause for these vulnerabilities lies in the way Trojitá (and many other mail clients) handle partially encrypted multipart messages.
*Leaking plaintext through reply/forward*
/Attacker model/: Attacker is in possession of PGP or S/MIME encrypted messages, which she may have obtained as passive man-in-the-middle or by actively hacking into the victim's mail server or gateway
/Attacker's goal/: Leak the plaintext by wrapping the ciphertext part within a benign-looking MIME mail sent to and decrypted+replied to by the victim
/Attack outline:/ If Trojitá receives a multipart email, as depicted below, it decrypt the ciphertext part(s), together with the attacker-controlled text (which may be prepended and/or appended).
|--- Attacker's part
|--- [encrypted part]
+--- Attacker's part
A benign-looking attacker's text may lure the victim into replying. Because the decrypted part is also quoted in the reply, the user unintentionally acts as a decryption oracle. To obfuscate the existence of the encrypted part(s), the attacker may add a lot of newlines or hide it within a long conversation history. A user replying to such a ‘mixed content’ conversation thereby leaks the plaintext of encrypted messages wrapped within attacker-controlled text.
Do not decrypt emails unless the PGP or S/MIME encrypted part is the root node -- and therefore the only part -- in the MIME tree (exception: multipart/signed for encrypted-then-signed S/MIME messages). Another, potentially less secure, option would be to quote only the very first MIME part in replies.
Created attachment 118286 [details]
Please find attached a raw .eml file which depicts the issue for PGP.
Created attachment 118287 [details]
Please find attached a raw .eml file which depicts the issue for S/MIME.
Hi Jens, thanks for sharing results of your research. This is a nice attack indeed.
Is this reprocible with a snapshot taken from git sources?
Is this reproducible with a snapshot taken from git sources?
(In reply to Raphael Groner from comment #5)
> Is this reproducible with a snapshot taken from git sources?
Yes, it is still valid. We do not have any countermeasure for this at this time. Patches welcome.
Update: Here's a full (public) report on the issue:
For Trojitá, CVE-2019-10734 was assigned for reply-based `decryption oracles`.
Is this being actively worked on?
> Do not decrypt emails unless the PGP or S/MIME encrypted part is the root node
> -- and therefore the only part -- in the MIME tree (exception: multipart/signed
> for encrypted-then-signed S/MIME messages). Another, potentially less secure,
> option would be to quote only the very first MIME part in replies.
Ping? I just got reminded of this CVE by the Fedora EOL bot (due to the impending Fedora 29 end of life).
Patch for review is available at https://gerrit.vesnicky.cesnet.cz/r/1038
Git commit 8db7f450d52539b4c72ee968384911b6813ad1e7 by Jan Kundrát.
Committed on 26/06/2020 at 10:29.
Pushed by jkt into branch 'master'.
Prevent a possible decryption oracle attack
Thanks to Jens Mueller (Ruhr-Uni Bochum and FH Münster) for reporting
this. The gist is that an attacker can embed arbitrary ciphertext into
their messages. Trojita decrypts that, and when we hit reply, the
original *cleartext* gets quoted and put into a reply for the attacker
Fix this by not quoting any plaintext which originated in an encrypted
message. That's pretty draconian, but hey, it works and we never came up
with any better patch. Also, given that Trojita does not encrypt
outgoing messages yet, this is probably also a conservative thing to do.
M +2 -0 src/Cryptography/GpgMe++.cpp
M +8 -1 src/Gui/MessageView.cpp
M +8 -0 src/Gui/PartWidget.cpp
M +1 -1 src/Imap/Model/ItemRoles.h