In the scope of academic research in cooperation with Ruhr-University Bochum and FH Münster, Germany we discovered weaknesses in Enigmail that allow signature spoofing/wrapping.
The first issue is simple:
Given her own text, the attacker wants to spoof a correct signature of someone else to be displayed. We assume she is already in possession of a valid signature from the entity of interest, which she obtained from email correspondence, public mailing lists, signed software packages, signed GitHub commits, etc. This should be a realistic scenario, so we don't even need an NSA-like attacker.
Now, the attacker simply attaches the signed message to a MIME multipart/mixed tree which already contains her own message:
multipart/mixed |--- text/plain (arbitrary text) +--- text/plain (PGP/INLINE signed text)
Or similar for PGP/MIME messages:
multipart/mixed
|--- text/plain (arbitrary text)
+--- multipart/signed
+--- multipart/mixed
+--- text/plain (whatever has been signed)
+--- application/pgp-signature
The whole message is displayed as correctly signed -- while only the second part should be marked as signed. The original message is still displayed, so if we don't get the entity to sign a common string ("Goodbye", empty string, her email signature, some binary data from a software package, etc.) this should be suspicious for a reader who scrolls down. Anyway, Enigmail should make it clear which body part is signed and which is not (as done for simple PGP/INLINE messages).
For a proof-of-concept, we have created an email message (see attached enigfail.tgz) which displays as correctly signed from Phil Zimmermann, based on a message he wrote in back 2001: https://philzimmermann.com/text/PRZ_leaves_NAI.txt -- to reproduce, import his key: https://philzimmermann.com/text/PRZ_keys.txt
...and verify the attached .eml file which depicts the problem.
The second issue is worse:
With multipart/related, it is possible to refer to a message part from another message part (which, for example, allows embedding images in HTML emails). This can be used to include a signed message part using the cid: URI scheme (see RFC2392) without actually showing it.
multipart/related
|--- text/html (DIESER TEXT)
<iframe src="cid:pgp-signed-message>
|--- multipart/signed
Content-ID: <pgp-signed-message>
[...]
The signed message is however still processed and the whole email is marked as correctly signed. Obviously, this is not a crypto problem, but a serious display problem.
Again, find attached a proof-of-concept .eml file which gets displayed as correctly signed by Phil Zimmermann, even though the attacker can insert arbitrary text here. This issue is worse than the one mentioned before, because the attacker basically controls the whole (displayed) content and the original text by Phil Zimmermann is not shown anymore at all. This gives an attacker the possibility to completely fake messages which are shown as correctly signed.
The attached file is a .tgz, but it contains a HTML page with the sourceforge login. That's not exactly what you promised ;-)
@patrick weird, the .tgz file is valid for me (maybe a sourceforge auth issue for attachments and bugs marked 'private'?). Anyway, re-uploaded the tarball's content here:
http://thelorg.org/enigfail/
Thanks, yes I can see that both are wrong. The problem is that there is not relation between the backend code and the GUI. In other words, Enigmail doesn't know which part of the displayed data in the GUI it got from Thunderbird. I already have several "fixes" for messages like these.
But this should be fixed in Enigmail, right? Or is it a Thundebird issue for you?
Last edit: Jens Müller 2017-10-16
Yes, it needs fixing in Enigmail.
I fixed both issues. The first is fixed by detecting if the 1st displayed message part is equal to the message part decrypted/signed. If not, there is no Enigmail header.
This doesn't work for multipart/related messages, where Thunderbird displays a different message part than it says. Therefore, if a signed (or encrypted) MIME part is a child of a multipart/related message, I will not display the Enigmail header line.
I will also add a check to determine if there are unsigned/unencrypted message parts after the 1st message part, and if so warn the user.