Hey, For S/MIME the situation is that it is a conceptional weakness in the standard to remove the target vector completely.
In KMail we have the best handling that we can get at the moment (with default settings). KMail never access resources from the internet without asking the user or an explicit change of the default setting: Settings > Configure KMail > Security > Reading > Allow messages to load external references from the Internet There are some small patches, that disable this setting for encrypted messages, to enforce a user interaction: https://phabricator.kde.org/D12391 https://phabricator.kde.org/D12393 https://phabricator.kde.org/D12394 For me applying the patches makes sense to improve security for users, but disabling the external resource loading completely would break workflows. Those patches are applied for the following Debian packages, where the setting is used for everything: libmessageviewer5 << 4:18.04.1 kmail < 4:18.04.1 As already mentioned, the underlying problem is the S/MIME conceptional weaknes, that can't be fixed by those patches. The stack KMail is using for decryption is GPGME Qt backend that is packaged in gpgme1.0 for testing/sid and gpgmepp for stable and older. I'm not sure, how this should be handled in Debian correctly. For a more detailed look for KMail and EFail see the dot.kde article: https://dot.kde.org/2018/05/15/efail-and-kmail hefee -- On Montag, 14. Mai 2018 15:33:02 CEST Yves-Alexis Perez wrote: > Source: kmail > Severity: grave > Tags: security > Justification: user security hole > > Hi, > > as you may already know, a paper was published this morning describing a > vulnerability known as efail against S/MIME and PGP/MIME implementations > in various mail clients. > > This vulnerability allows an attacker with read/write access to > encrypted mail to retrieve the plaintext provided HTML mails are > enabled, as well as loading of remote content. > > The paper indicates that the PGP/MIME implementation in kmail is not > vulnerable, but the S/MIME is. > > It might be possible that the vulnerability is in an underlying library, > so feel free to reassign if needed. > > It's likely we'll have to issue a DSA for this. > > Regards,
signature.asc
Description: This is a digitally signed message part.
