1646404 - multipart/mixed with multipart/signed messages delivered with broken MIME structure at PGP Proxy API

Status: RESOLVED INVALID

(MailNews Core :: Security: OpenPGP, defect, P1)

Description

[Jorg K (CEST = GMT+2)]

Enclosed the MIME text delivered at the PGP Proxy API. It is correct in TB 68 but broken in TB 78. Look for the string 7096113637923985010 to see the broken MIME structure of the message delivered in TB 78.

Comment 1

[Jorg K (CEST = GMT+2)]

Attachment: msg68.txt - MIME text delivered in TB 68

Please ignore the additional empty lines resulting from copy/paste from the console.

Comment 2

[Jorg K (CEST = GMT+2)]

Attachment: msg78.txt - MIME text delivered in TB 78

This has a broken multipart/mixed structure, the boundary is 7096113637923985010 but that doesn't occur in the file. Download the two attachments and diff them to see the damage.

Comment 3

[Jorg K (CEST = GMT+2)]

Looks like the issue is caused in EnigmailVerify.registerContentTypeHandler() and friends. This code can be nuked by PGP Add-ons like so:

var { EnigmailVerify } = ChromeUtils.import("chrome://openpgp/content/modules/mimeVerify.jsm");
EnigmailVerify.registerContentTypeHandler = () => null;

Comment 4

[Kai Engert [:KaiE:]]

Is this a broken functionality in the product, or is the problem limited to affecting extension software?

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to Kai Engert (:KaiE:) from comment #4)

Is this a broken functionality in the product, or is the problem limited to affecting extension software?

Comment 7

[John Bieling]

(In reply to Wayne Mery (:wsmwk) from comment #6)

(In reply to Kai Engert (:KaiE:) from comment #4)

Is this a broken functionality in the product, or is the problem limited to affecting extension software?

I do not know what the "PGP Proxy API" is, and I do not think this is related to WebExtension APIs. WebExtension Experiments of course can interact with core code as described in Comment #3. From what I understood, this is a bug in core, which could be fixed by Comment #3 (which could be done in core or by a WebExt Experiment).

Has anybody been able to reproduce the reported bug? Is there a STR?

Comment 8

[Kai Engert [:KaiE:]]

I was not involved in the development of that Proxy API.

I assume it was a past mechanism that allowed the Enigmail extension to plug into MIME message processing and decode/process received OpenPGP messages.

The former Enigmail code was moved to the core of Thunderbird. Our code most likely still uses the same mechanism.

My understanding is, the bug was reported by a member of the pEp software team. That group develops an Add-On that replaces Thunderbird's internal OpenPGP feature with modified functionality.

My question 4 wasn't answered. I assume that this bug doesn't affect Thunderbird itself. I'm guessing the bug report only affects the external pEp Add-On.

We need to investigate if my assumption is correct (Thunderbird itself not being affected).

We also could discuss if we want to continue to offer the API for external Add-ons, or not.

Comment 9

[Barbara]

(In reply to Kai Engert (:KaiE:) from comment #4)

Is this a broken functionality in the product, or is the problem limited to affecting extension software?

The problem is, as the summary states, that the content of multipart/mixed with multipart/signed messages is delivered with broken MIME structure at the PGP Proxy API. Violation of a defined API in itself constitutes broken product functionality. TB itself doesn't suffer from the API violation since the message is displayed correctly. However, the pEp add-on does it's own MIME parsing which fails on the broken MIME structure.

Since in TB 102 the ability to switch off TB's OpenPGP altogether (pref mail.openpgp.enable), we had to re-implement the hack we mentioned:
https://pep-security.lu/gitlab/thunderbird/pEpForThunderbird/-/commit/cb0dad933d477ab08687f04aab312b39f6389d59

Comment 10

[Kai Engert [:KaiE:]]

I see that TB's integrated OpenPGP code still relies on nsIPgpMimeProxy and our internal nsPgpMimeProxy implementation in C++, the code is reached when processing an encrypted OpenPGP message.

This bug report claims that for a multipart MIME message, the multipart/signed header is missing.
It wasn't said which function receives the broken data.

I'm looking at the attachments, and they contain FULL messages. This surprises me. I've looked at the data that our code sends to the proxy API. It doesn't contain the outer message headers (with routing headers), only the inner content types, and those parts seem complete.