Bug 404697 - CVE-2019-10734: Decryption Oracle based on replying to PGP or S/MIME encrypted emails
Summary: CVE-2019-10734: Decryption Oracle based on replying to PGP or S/MIME encrypte...
Status: RESOLVED FIXED
Alias: None
Product: trojita
Classification: Applications
Component: Cryptography (show other bugs)
Version: 0.7
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Trojita default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-22 12:44 UTC by Jens Mueller
Modified: 2020-06-26 17:37 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Proof-of-concept PGP (1.68 KB, message/rfc822)
2019-02-22 12:44 UTC, Jens Mueller
Details
Proof-of-concept S/MIME (1.48 KB, message/rfc822)
2019-02-22 12:45 UTC, Jens Mueller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Mueller 2019-02-22 12:44:06 UTC
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).

multipart/mixed
   |--- 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.

---------------
Countermeasures
---------------

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.
Comment 1 Jens Mueller 2019-02-22 12:44:43 UTC
Created attachment 118286 [details]
Proof-of-concept PGP

Please find attached a raw .eml file which depicts the issue for PGP.
Comment 2 Jens Mueller 2019-02-22 12:45:14 UTC
Created attachment 118287 [details]
Proof-of-concept S/MIME

Please find attached a raw .eml file which depicts the issue for S/MIME.
Comment 3 Jan Kundrát 2019-02-24 15:46:25 UTC
Hi Jens, thanks for sharing results of your research. This is a nice attack indeed.
Comment 4 Raphael Groner 2019-04-16 17:50:47 UTC
Is this reprocible with a snapshot taken from git sources?
Comment 5 Raphael Groner 2019-04-16 17:51:19 UTC
Is this reproducible with a snapshot taken from git sources?
Comment 6 Jan Kundrát 2019-04-17 07:27:41 UTC
(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.
Comment 7 Jens Mueller 2019-04-18 13:37:37 UTC
Update: Here's a full (public) report on the issue:
https://arxiv.org/ftp/arxiv/papers/1904/1904.07550.pdf

For Trojitá, CVE-2019-10734 was assigned for reply-based `decryption oracles`.
Comment 8 Fabian Vogt 2019-07-12 07:19:27 UTC
Is this being actively worked on?

> Countermeasures
> ---------------
> 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.
Comment 9 Kevin Kofler 2019-10-31 22:38:31 UTC
Ping? I just got reminded of this CVE by the Fedora EOL bot (due to the impending Fedora 29 end of life).
Comment 10 Jan Kundrát 2020-06-26 10:30:40 UTC
Patch for review is available at https://gerrit.vesnicky.cesnet.cz/r/1038
Comment 11 Jan Kundrát 2020-06-26 17:37:47 UTC
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
to see.

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.

Change-Id: I84c45b9e707eb7c99eb7183c6ef59ef41cd62c43
CVE: CVE-2019-10734

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

https://invent.kde.org/pim/trojita/commit/8db7f450d52539b4c72ee968384911b6813ad1e7