Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Treat [new] encrypted messages without MDC as broken #2075
We should probably treat new encrypted messages without a valid MDC as broken and dangerous.
Allowing users to still decrypt and read old mail from their archives should still be fine. Mailpile already has mitigation in place against forged date headers, so we can probably implement this sort of nuanced defense against the few remaining edge-cases where EFail is theoretically exploitable.
Backstory: (see also: https://www.mailpile.is/blog/2018-05-14_PGP_Security_Alert.html)
GnuPG will decrypt without an error some messages lacking the MDC integrity checks, as long as they are also encrypted using obsolete ciphers. So these messages are theoretically vulnerable to EFail style attacks.
Note that step 2 will require some social engineering, as Mailpile will by default not render the HTML at all - so the attacker will need to engage the user's attention enough to get them to manually enable both the HTML and remote images. This also means the risk of detection for the attacker is VERY high, since a) the user will have interacted with the e-mail and b) the attacking e-mail itself contains links to the attacker's data harvesting server.
For these reasons, this attack is very unlikely to be exploited in the wild; attackers with the technical skills to pull this off will generally not want to risk detection - especially not when the only data they can harvest is likely to be 10-20 years old.
My current take is that this is very low risk, but probably still worth mitigating as part of our overall defense in depth approach.
Re-opening: We should update the logic in gpgi.py to match what is described by Werner, here: https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060421.html - our current approach is brittle if Werner ever decides to change the text of the warning message (or if that string is subject to i18n).
I reviewed this for some time because I wanted to contribute but, as far as I can begin to understand, this logic is already handled in gpgi.py.
From what I understand from the link you provided, so long as Mailpile is configured to use an up-to-date version of GnuPG, it seems the GnuPGResultParser will receive DECRYPTION_FAILED in the case you wanted to handle for in gpgi.py already.
I've only been looking at Mailpile for a few hours so forgive me if I'm mistaken. If I am and you can clarify, I'd be more than happy to make proposed changes.
This is the problem: "as long as Mailpile is configured to use an up-to-date version of GnuPG."
Current versions of GnuPG will happily decrypt without an error certain messages that lack an MDC, because older version of the PGP spec did not include an MDC. Changing the defaults and breaking compatibility by default was discussed on the GnuPG users list only last month. I think the decision was made to do this (bit I'm not sure) - but considering how the GnuPG community has consistently downplayed this entire issue and claimed it's "just an e-mail client bug," even if that decision is made it may not be publicized and advertised as critical security fix - so it may not get picked up by the distro security teams, and may not become available to the general public until the next major release of whatever distro they use.
Furthermore... even if this change is made, will it be backported to GnuPG 1.4 (which Mailpile uses on some older platforms)? I don't know. Again, since Werner et. al. don't seem to consider this a serious issue, I have my doubts.
So the idea here is to go further than the GnuPG defaults, so as to protect people who are not fully up to date, and to protect people in the case where the GnuPG team behaves consistently with their repeated claims that this issue is no big deal.
Incidentally, if we want to allow users to read old mail with a NEW version of GnuPG that has changed this default, then we need to add support for whatever flag GnuPG provides to enable the old behaviour. So there's still work to be done here, even if we assume current versions of GnuPG behave in a secure way by default.