Hi all, this week an interesting paper about attacks against MUA's supporting OpenPGP and S/MIME signatures has been published [1]. Instead of attacking the crypto layer, the authors show methods for spoofing digital signatures. Opening the proof-of-concept messages available from the authors [2] in Balsa unfortunately shows some vulnerabilities which I will try to fix as soon as possible. Note that the multipart/signed PGP samples are not recognised by Balsa as they miss the required 'micalg' parameter [3]; I added it for my tests. A brief summary of the test results, running the latest Balsa master build on Ubuntu 18.04 LTS, which comes with gpg 2.2.4, gpgsm 2.2.4 and gpgme 1.10.0: - Perfect forgery: C2 - Partial forgery: I1, I2, I3 - Weak forgery: M3 (inline PGP only), M4 (inline PGP only), U1 - Not vulnerable: C1, C3, C4, G1, G2, M1, M2, M3 (multipart/signed only), M4 (multipart/signed only) Cheers, Albrecht. --- A more detailed evaluation of the test cases: (1) CMS Attack Class C1 – eContent Confusion: Balsa is *not* vulnerable, showing an error message that the signature could not be verified. Possible minor improvement: The signature info in the message /still/ displays the “Signature validity” and “Signed on” fields which should be hidden. C2 – Multiple Signers: Balsa *is* vulnerable (perfect forgery), as only the first signature is evaluated. Fix: do not accept multiple signers as proposed in section 6.1 of the paper. C3 – No Signers: Balsa shows a gray padlock, no signature info in the headers and the body sections, but the frame with gray padlock around the allegedly signed content. As this may be confusing for the user, the frame /might/ be omitted in this case. However, given the criteria in the paper, Balsa is *not* vulnerable, as nothing actually indicates a good signature. C4 – Trust Issues: No test sample has been provided, but I /think/ that Balsa is not vulnerable, as gpgsm (via gpgme's gpgme_signature_t::summary and gpgme_signature_t::validity items) will mark untrusted certificates. (2) GPG API Attack Class As Balsa uses GpgME to talk to GPG, it is *not* vulnerable by this attack class [4]. (3) MIME Attack Class M1 – Prepend Attacker's Text: Inline PGP: Balsa shows a valid signature info in the headers and below the signed part, but clearly indicates which part of the message is signed. I.e. Balsa is not vulnerable. Multipart/signed, both PGP and S/MIME: as Balsa considers only multipart/signed (and multipart/encrypted) parts which are the first child of the parent container for crypto processing, the contents (both parts) is displayed without any crypto hints. I.e. Balsa is not vulnerable. Note that some mailing list processors (like gnome.org's) put the multipart signed as /first/ part of a multipart/mixed, followed by the text/plain containing the list info. In this case, the signature /is/ evaluated, but Balsa clearly indicates which part is actually covered by the signature. M2 – Hiding signed part with HTML Inline PGP: looks as with M1 for Inline PGP if split into two parts (multipart/mixed). The variant consisting of a single part only (PoC messages M2 #2) do not evaluate the inlined signed stuff at all, as Balsa requires it to start at the very beginning of the respective MIME part. Balsa is not vulnerable. Multipart/signed, both PGP and S/MIME: same as for M1 multipart/signed; not vulnerable. M3 – Hiding Signed Part in Related Content Inline PGP: cid:target is ignored. The signed part is evaluated, but not displayed (in contrast to the similar cases for M1 and M2, still have to check why). In the headers, Balsa indicates a valid signature, but of course *no* crypto frame is drawn. As this may be confusing, this could be considered a weak forgery. Multipart/signed, both PGP and S/MIME: the part is neither evaluated nor displayed (see above); not vulnerable. M4 – Hiding Signed Part in an Attachment Inline PGP: looks similar to M3 Inline PGP; weak forgery. Multipart/signed, both PGP and S/MIME: parts are displayed, no crypto processing (see above); not vulnerable. (4) ID Attack Class I1 – Not Checking If Sender == Signer Balsa shows a “good signature” message in the headers section. The user has to open the signature details at the bottom of the crypto frame to see that the signature's uid does not match the sender. According to the paper's criteria, this is a partial forgery. Fix: display the senders email and/or name/CN in the headers, as proposed in sect. 6.4 of the paper. I2 – Display name Shown as Signer Same situation and fix as I1. As for the missing, malformed or duplicated From: headers violating RFC 5322, sect. 3.6.2, we might additionally pop up a warning. I added a facility to GMime 3.2 for easily detecting such cases (and a lot more, typically used in (mal-)spam campaigns), so we might want to postpone this approach until we migrated to GMime 3.2. In the “from is sender . <signer>” and “from is sender <signer>” cases we don't show the full header; I have to dig deeper into this issue (which may actually be a GMime one). I3 – From/Sender Header Confusion Same situation and fix as I1. As for the messages with multiple From: addresses, but without Sender: (which also violates RFC 5322), we could again pop up a warning. Additionally, we should add Sender: to the list of headers displayed by the selected headers option. (5) UI attack class A carefully crafted HTML-only message may actually look exactly like a message with a good signature, but - the signature indicator in the headers will be missing, - the padlock icon in the message list (which, if multiple signed parts exist, will always show the worst status of all signatures, btw.) will be missing, - it may be difficult to implement the full functionality of Balsa's signature widget (expander, buttons, …) in HTML and - matching the user's theme/style settings is probably difficult (but of course feasible for a targeted attack). According to the paper's criteria, this is a weak forgery, unless combined with other methods which could result in partial forgery. Defending against this attack class is a real challenge. We could (like kmail) clearly mark HTML parts and/or display HTML parts as text and interpret it on request only. We should also make the description of the option to prefer text/plain over html clearer; e.g. by adding something like “HTML in Emails should always be considered a security risk” (I'm no native speaker, sorry, please provide a better message…). [1] <https://raw.githubusercontent.com/RUB-NDS/Johnny-You-Are-Fired/master/paper/johnny-fired.pdf> [2] <https://github.com/RUB-NDS/Johnny-You-Are-Fired> [3] <https://mailarchive.ietf.org/arch/msg/openpgp/SKclvRGw9kan13GSsP66NlHHKEc> [4] <https://mailarchive.ietf.org/arch/msg/openpgp/uSSw9jY-wXo_hk9Af-fpro91DVM>
Attachment:
pgp6AhB9VQNgM.pgp
Description: PGP signature