In the scope of academic research in cooperation with Ruhr-Uni Bochum and FH Münster, Germany we discovered a security issue in Claws: An attacker who is in possession of PGP encrypted messages can append them to her own text. If the victim replies, the plaintext is leaked to an attacker's email address. ----------------------------------- *Leaking plaintext through replies* ----------------------------------- /Attacker model/: Attacker is in possession of PGP 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 within a benign-looking email sent to and decrypted+replied to by the victim /Attack outline:/ If Claws receives a text/plain email as depicted below, it decrypt the ciphertext part(s), and shows it together with the attacker-controlled text (which may be prepended and/or appended). [Attacker's text] -----BEGIN PGP MESSAGE----- [Unknown ciphertext] -----END PGP MESSAGE----- [Some more attacker's text] A benign-looking attacker's text may lure the victim into replying. Because the decrypted text is also quoted in the reply, the user unintentionally acts as a decryption oracle. To obfuscate the existence of the encrypted text, 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. This attack works for PGP/INLINE and PGP/MIME captured ciphertexts because PGP/INLINE can be downgraded to PGP/MIME. Another option to perform the attack is by using multipart emails with PGP or S/MIME encrypted parts, as depicted below: multipart/mixed |--- Attacker's part |--- [encrypted part] +--- Attacker's part Again, Claws decrypts the ciphertext part(s), together with the attacker-controlled text. However, the only the first part is included in the reply (unless the user marks then whole message text). This attack works for PGP/MIME and S/MIME captured ciphertext. --------------- Countermeasures --------------- Do not decrypt encrypted emails unless there is only one single encrypted text/part.
Created attachment 1960 [details] Proof-of-concept PGP
Created attachment 1961 [details] Proof-of-concept S/MIME
Just for clarification - by: "[...] because PGP/INLINE can be downgraded to PGP/MIME." ^^^^^^^^ ^^^^^^^^^^ did you mean the opposite? "[...] because PGP/MIME can be downgraded to PGP/INLINE." ^^^^^^^^ ^^^^^^^^^^ I can certainly reproduce this (and anyone working on this will have to reproduce it with PGP message blocks encrypted to their secret keys), and agree that this is an issue. I am however unsure how to best solve it without blocking users from legitimate uses of inline PGP. I think we should focus on the first described case (PGP/Inline), as I do not consider the latter case (plaintext leak via PGP/Mime and PGP/SMIME replies) really a leak - if the user explicitly selects the decrypted plaintext for inclusion into a reply, it is reasonable to assume that they want to include it there. Ideas: 1. Require that a PGP/Inline message is at the very beginning of the message body (or a text/plain message part), otherwise do not even attempt to decrypt it. This is rather easy to implement, and would be an ideal solution if we could assume that users always want to protect the entire message body, and not just some critical part in the middle (something analogous to "[spoiler]...[/spoiler]" tags on various web forums). Admittedly, that sort of usage is probably quite rare, but possible. 2. Display a warning dialog on starting a reply if the quoted text would include a mix of unencrypted and (originally) encrypted text, and let the user decide how to proceed. This would be slightly more difficult to implement, since at that point in the code, the entire displayed content is already decrypted, and there is no programmatic way to determine which portions were originally encrypted. However, I think it could be done by adding GtkTextMarks around the decrypted content when the message is being decrypted and displayed.
> did you mean the opposite? > "[...] because PGP/MIME can be downgraded to PGP/INLINE." > ^^^^^^^^ ^^^^^^^^^^ Yes :) As in: the attacker captures a PGP/MIME encrypted email (which should be more common these days), but places it into the body of a text/plain message to enforce the user agent to interpret it as PGP/INLINE. Personally, I'm not a friend of letting users decide. Imho option 1) should be fine, as no sane user agent should produce plaintext||pgp-inline-encrypted. (However, copying + pasting ascii armored ciphertext and an additional text could produce such a message. On the other hand, in such cases it can be assumed that the communication partners want to manually encrypt/decrypt the message on the command line anyway.) One more thing to think about, in case option 1) is implemented, is that the attacker can encrypt her text to: -----BEGIN PGP MESSAGE----- [Attacker's ciphertext] -----END PGP MESSAGE----- -----BEGIN PGP MESSAGE----- [Unknown ciphertext] -----END PGP MESSAGE----- Therefore, only one single ascii armored data blob per message (or per MIME part) should be accepted (again, no sane UA should produce multiple blobs within one message part, correct?) In any case, for Claws this issue is somewhat limited because it affects "only" careless users who do not scroll down the entire communication history. In various other email clients, the encrypted part can be completely hidden with HTML/CSS when receiving and replying to a message which is much worse. Therefore: Yet another good reason to *not* support HTML email :)
Update URL with the CVE assigned to this one.
Update: Here's a full (public) report on the issue: https://arxiv.org/ftp/arxiv/papers/1904/1904.07550.pdf
(In reply to comment #4) > One more thing to think about, in case option 1) is implemented, is that the > attacker can encrypt her text to: > > -----BEGIN PGP MESSAGE----- > [Attacker's ciphertext] > -----END PGP MESSAGE----- > -----BEGIN PGP MESSAGE----- > [Unknown ciphertext] > -----END PGP MESSAGE----- > > Therefore, only one single ascii armored data blob per message (or per MIME > part) should be accepted (again, no sane UA should produce multiple blobs > within one message part, correct?) This is not a problem - the entire message body (for inline) or part (for MIME) is fed to libgpgme, which errors out with "Bad data", because of multiple PGP blocks. Claws Mail then falls back to displaying the encrypted message as is (for inline) or displaying nothing (for MIME). A fix for this bug will not change behavior described here.