New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Treat [new] encrypted messages without MDC as broken #2075

Closed
BjarniRunar opened this Issue May 14, 2018 · 10 comments

Comments

Projects
None yet
3 participants
@BjarniRunar
Member

BjarniRunar commented May 14, 2018

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.

  1. Steal some old mail that is encrypted with obsolete ciphers
  2. Forge a specially crafted message to try and trick Mailpile into decrypting it and sending the contents back

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.

@BjarniRunar

This comment has been minimized.

Member

BjarniRunar commented May 15, 2018

Relates to #733.

@BjarniRunar

This comment has been minimized.

Member

BjarniRunar commented May 15, 2018

This is done, with a default of requiring an MDC for all messages. Users wishing to index and read very old mail will need to change the prefs.weak_crypto_max_age setting.

@BjarniRunar

This comment has been minimized.

Member

BjarniRunar commented May 17, 2018

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).

@stoksc

This comment has been minimized.

Contributor

stoksc commented Jun 26, 2018

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.

@BjarniRunar

This comment has been minimized.

Member

BjarniRunar commented Jun 26, 2018

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.

@BjarniRunar

This comment has been minimized.

Member

BjarniRunar commented Jun 26, 2018

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.

@stoksc

This comment has been minimized.

Contributor

stoksc commented Jul 2, 2018

I understand completely now. Thanks for clarifying. If I have time, I'll submit a pull request with these changes.

@stoksc

This comment has been minimized.

Contributor

stoksc commented Jul 4, 2018

Just opened a PR, let me know what you think. Used this that you originally linked as a reference and just implemented the same logic.

@vezult

This comment has been minimized.

Contributor

vezult commented Sep 26, 2018

Looks like this has been inactive for a long time. I've implemented the change suggested in the previous PR review, and submitted a new PR

@BjarniRunar

This comment has been minimized.

Member

BjarniRunar commented Oct 25, 2018

This is done. Thanks everyone!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment