From 38fa2dab97180dc61a7b0582984f36ba6d8eb93c Mon Sep 17 00:00:00 2001 From: =?utf8?q?Jan=20Kundr=C3=A1t?= Date: Mon, 21 May 2018 11:42:01 +0200 Subject: [PATCH] crypto: EFAIL: clarify that we handle broken encrypted messages properly If a message that is encrypted fails the decryption for some reason, gpg might still provide us with its plaintext. That can happen when the MDC (Modification Detection Code) indicates that it's been tampered with, for example. As per upstream's recommendations, we've been always ignoring the cleartext in that case. Let's clarify that this is on purpose as a part of a defense-in-depth approach. Our HTML renderer still would not request external entities and therefore it won't leak the cleartext to the adversary. Change-Id: Ic5b175a7d230ccdb99d74902782a01aa09339c14 --- src/Cryptography/GpgMe++.cpp | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/Cryptography/GpgMe++.cpp b/src/Cryptography/GpgMe++.cpp index 0ba37c06..e012f603 100644 --- a/src/Cryptography/GpgMe++.cpp +++ b/src/Cryptography/GpgMe++.cpp @@ -925,7 +925,10 @@ void GpgMeEncrypted::processDecryptedData(const bool ok, const QByteArray &data) mimetic::MimeEntity me(data.begin(), data.end()); m_model->insertSubtree(idx, MimeticUtils::mimeEntityToPart(me, nullptr, 0)); } else { - // offer access to the original part + // It's important that we do not render this message if the decryption actually failed. + // One form of the EFAIL attack from 2018 relied on MUAs which HTML-rendered the decrypted plaintext + // which was however mangled by an attacker. + // We just offer access to the original, encrypted part as-is for further processing. std::unique_ptr part(new LocalMessagePart(nullptr, 0, m_encPart.data(RolePartMimeType).toByteArray())); part->setBodyDisposition("attachment"); part->setFilename(m_encPart.data(RolePartFileName).toString()); -- 2.11.4.GIT