Hello, I'd like to discuss a security problem, but we don't want to make it public right now. Can this issue be set to confidential?
(In reply to Damian Poddebniak from comment #0) > Hello, I'd like to discuss a security problem, but we don't want to make it > public right now. Can this issue be set to confidential? Hi, I don't know how to do that with our Bugzilla instance (and my permission level). A best course of action is probably mailing me directly (jkt@kde.org, GPG key 94612A6CBDDA8C7F5095BEB31B364DA3AAD4170A).
(In reply to Damian Poddebniak from comment #0) > Hello, I'd like to discuss a security problem, but we don't want to make it > public right now. Can this issue be set to confidential? Please follow https://www.kde.org/info/security/
So... should I write to Jan Kundrat or e.g. David Faure? This issue is trojita-specific.
Jan.
I got a description of the possible bug by an encrypted e-mail -- thanks for that. Thomas, Caspar, Erik, Stephan, Pali -- if you're interested in it and if you're OK with keeping it confidential per Damian's terms, please reply here with your GPG key fingerprint and I'll share the information. I'm very busy with real life at the time, so please allow for longer responses than usual.
I would like to look into this issue (stephan@stephan-platz.de, FBA2C336A60037576EAEC5C72BB88734955D8A24)
This appears to have gone public now. Technical details are available in the paper [1]. Trojita is listed as vulnerable (page 20) for two classes of exfiltration scenarios: - I3: "CRL requests to a fixed CA URL are performed for valid/trusted S/MIME signed emails" - H3, which is about the DNS prefetch control: <meta http-equiv="x-dns-prefetch-control" content="on"><a href="http://efail.de"></a> The I3 is outside of control of Trojita. We are using the libgpgme library for all crypto operations, including the CRL handling. We do not issue any cert/CRL/key/... requests directly. Once gpgme is fixed, Trojita will be fixed, too. The H3 has been reported in bug 390452, and that's upstream https://bugreports.qt.io/browse/QTBUG-67068 . Our code has always included explicit disabling of the DNS prefetch for QtWebKit; unfortunately, due to a bug in upstream qtwebkit, this does not take any effect. We *could* try to mitigate the problem by mangling the HTML code, trying to insert an explicit <meta> element which disables this DNS prefetch. However, these attempts tend to be error-prone because there are many ways on how to re-enable various features in HTML renderers. There are other attacks as well. The user is still presented with a button to enable remote content when displaying encrypted e-mails. That should probably be disabled in order to make sure that the plaintext content won't leak by accident. [1] https://efail.de/efail-attack-paper.pdf