1994709 - Restore the ability to view remote content in OpenPGP messages (undo bug 1925929)

Status: NEW

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[Kai Engert [:KaiE:]]

Motivated by finding a solution for bug 1931550, I wonder whether our change in bug 1925929 might have been exaggerated and could be reverted.

When Magnus discovered that we allowed OpenPGP messages to allow loading of remote content (assuming the user's approval), but we never allowed that for S/MIME message, it seemed like it was an oversight. We decided in favor of security, and decided to extend the general blocking to OpenPGP messages, too.

Let's look at the situation in more detail.

The scenario:
Alice sends an encrypted message to Bob.
Eve captures a copy of the encrypted message and cannot decrypt it.
Eve tries to construct a crafted email and sends it to Bob, and hopes the Bob's email client will send the decrypted plaintext to a server chosen by Eve.

There are two general approaches how to do that:
(a) combining the encrypted payload with MIME parts
(b) changing the encrypted payload itself

Approach (a) requires that the MUA decrypts the contained parts, and combines it with related other parts. When doing so, the surrounding other parts could be used to inject the plaintext into network requests for loading remote message contents.

However, approach (a) should no longer be possible with current Thunderbird versions.

The default behavior is to skip encrypted message parts (not decrypt and not render them) unless the decrypted part is the top level MIME part.

Only one exception is allowed, which is, if the top level MIME part is a digital signature content-type, that part will be completely ignored. In that scenario, the encrypted MIME part must be the only child part of the top level signature part.
(This was allowed to support email gateways that add a signature layer to all outgoing messages.)

In addition, we have code that notifies the user when encrypted sub-parts are detected, and the user is offered to view them. However, this is done by loading the sub-part into a separate rendering window, which ignores all surrounding MIME parts (both upper layers and sibling layers).

It shouldn't be necessary to completely forbid loading of remote content to protect against attacks of approach (a).

With Approach (b) Eve inserts additional encrypted fragments in the middle of the original encrypted message. That's complex, but it has been shown that it can be done. The intention is to insert HTML statements in the middle of the original plaintext, that would cause Thunderbird to perform a network request when rendering the message, and submit parts of the plaintext together with the network request.

This works with some encryption modes, only.
It doesn't work with modern encryption modes that use MDC (OpenPGP, Modification Detection Code) or AEAD (authenticated encryption).

In short, with the modern modes, it's not possible to insert an additional part into the middle without breaking integrity checks. The individual blocks of an encrypted message are linked to each other. Only the original sender has the ability to create that linkage between the blocks while they are created.

That means, with a modern encryption mode, if Eve inserted another block, that will be detected as an integrity failure when decrypting the message.

In Thunderbird, when decrypting OpenPGP messages, we strictly enforce that MDC is used and is valid. We don't decrypt messages without MDC at all (e.g. see the complaint in bug 1731608).

I believe that means approach (b) cannot be used for the attack. Allowing loading of remote content can load only submit information that the original sender had intended to be sent to the network.

For S/MIME, the situation is different. Thunderbird's S/MIME implementation hasn't been updated much. I believe Thunderbird still allows rendering of messages that lack such a protection mechanisms. As a result, I believe that the attack (b) would still work if Thunderbird were to allow loading of remote content for encrypted messages.

Comment 1

[Kai Engert [:KaiE:]]

Because of the analysis above, it might be acceptable to undo bug 1925929 and restore the ability to load remote content for encrypted OpenPGP messages that contain MDC protection.

Nevertheless, we should continue to completely forbid loading of remote content for S/MIME messages. Once we implement support for the relevant S/MIME mechanisms, we could relax and allow loading of remote content for S/MIME messages that contain the protection.

Comment 2

[Kai Engert [:KaiE:]]

I would like to ask for feedback, whether the above reasoning makes sense.

Comment 3

[Magnus Melin [:mkmelin]]

Not easy to say. Attachment 8951568 [details] is one of the papers behind the original findings for decryption oracles. Skimmed it again. See section 7, and 5.2 - do we support symmetrical encrypted packet type which is apparently still vulnerable without any possibility to fix?

Comment 4

[Kai Engert [:KaiE:]]

(In reply to Magnus Melin [:mkmelin] from comment #3)

Not easy to say. Attachment 8951568 [details] is one of the papers behind the original findings for decryption oracles. Skimmed it again. See section 7, and 5.2 - do we support symmetrical encrypted packet type which is apparently still vulnerable without any possibility to fix?

RNP supports it.
However, Thunderbird rejects it.

What happens is:

• TB asks RNP to decrypt
• RNP will decrypt it, even if it uses the SE packet type without MDC
• TB queries how the data was protected.
• If neither MDC nor the more modern AEAD is found, or it's invalid, then RNP will report "invalid integrity protection"
• If RNP reported invalid, then TB will not use the returned data in any way (useDecodedData = false, status = DECRYPTION_FAILED)

see https://searchfox.org/comm-central/rev/835667286553c062db408cb3108fbf2a7eb421ea/mail/extensions/openpgp/content/modules/RNP.sys.mjs#2057,2071-2076

In other words, TB will refuse to process data that was decrypted from a SE packet without MDC, and it will refuse to process data from a SEIP packet if the MDC check failed.

Comment 5

[Kai Engert [:KaiE:]]

Given the cleanup that was done in bug 1925929, we shouldn't simply revert the earlier patch.
For an URI, in addition to remembering whether it was an encrypted message, we also need to remember whether the encrypted used integrity protection.
For our S/MIME code, this is currently always no, and for OpenPGP code, it's currently always yes.
I think remote content should be unconditionally blocked for encrypted messages without integrity protection, but should be allowed in other scenarios.

Comment 6

[Magnus Melin [:mkmelin]]

Seems worth investigating then I think.