2052070 - Remote content loading is wrongly allowed for encrypted messages when loaded from a file

Status: RESOLVED FIXED

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

Description

[Kai Engert [:KaiE:]]

While working on bug 1994709 I discovered that we're not completely blocking the load of remote content in encrypted messages.

When saving an encrypted message to a file, and then using file open to display the message, we will allow remote content loading (the remote content warning banner will allow overriding).

That problem applies for both S/MIME and OpenPGP messages.

It seems I have a fix in hand and will attach tomorrow.

Comment 1

[Kai Engert [:KaiE:]]

Note that it works as intended when a message is loaded from a folder. The fix from bug 1925929 works correctly in that scenario.

Comment 2

[Kai Engert [:KaiE:]]

The issue is that nsIEncryptedSMIMEURIsService isn't working sufficiently in all scenarios.

The code in msgHdrViewSMIMEOverlay.js and enigmailMsgHdrViewOverlay already registers two different URI presentations, but that's still different from what nsMsgContentPolicy::ShouldLoad uses ( aRequestingLocation->GetSpecOrDefault() ).

I think we should change nsIEncryptedSMIMEURIsService to use a canonical message ID.
We could do so by porting msgIdentificationFromUrl to C++.

Comment 3

[Kai Engert [:KaiE:]]

(In reply to Kai Engert [:KaiE:] from comment #2)

I think we should change nsIEncryptedSMIMEURIsService to use a canonical message ID.
We could do so by porting msgIdentificationFromUrl to C++.

This wouldn't cover necko/display URIs.
It's still easier to register twice, so the service doesn't need additional dependencies.

Comment 4

[Kai Engert [:KaiE:]]

Attachment: WIP: Bug 2052070 - Improve correctness of nsIEncryptedSMIMEURIsService lookups.

Comment 5

[Kai Engert [:KaiE:]]

Attachment: WIP: Bug 2052070 - Allow remote content for integrity-protected OpenPGP messages.

Comment 6

[Kai Engert [:KaiE:]]

The patch from comment 5 - https://phabricator.services.mozilla.com/D310222 - actually belongs to bug 1994709 - but it overlaps with the work from this bug here.

I don't want to expose this security sensitive bug yet, so I'm temporarily tracking that other patch in this bug (until this bug has been resolved).

Comment 7

[Wayne Mery (:wsmwk)]

I've set version to the current esr. Please adjust version if this is only a newer issue.

Comment 8

[Kai Engert [:KaiE:]]

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

I've set version to the current esr. Please adjust version if this is only a newer issue.

it's much older.

Comment 9

[Kai Engert [:KaiE:]]

I would like to unhide this bug.

I need to get it commited as a base patch for 1994709.
And while I think it should be backported to ESR, it's not clear whether it will.

The scenario is rather unusual.
And even if a user saves a message to a file and opens it from there, we still get the remote content blocking by default.

Comment 10

[Kai Engert [:KaiE:]]

Attachment: Bug 2052070 - Improve correctness of nsIEncryptedSMIMEURIsService lookups. r=mkmelin

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/c9d1fb051c45
Improve correctness of nsIEncryptedSMIMEURIsService lookups. r=mkmelin

Comment 12

[Kai Engert [:KaiE:]]

Reopening, because a follow-up patch is necessary to fix windows-only permanent test failure.
TEST-UNEXPECTED-FAIL | comm/mailnews/extensions/smime/test/unit/test_encryptedURIsService.js | test_differentQueryRepresentationsMatch - [test_differentQueryRepresentationsMatch : 28] the display URL must match the registered necko URL for the same message - false == true

Comment 13

[Kai Engert [:KaiE:]]

Attachment: Bug 2052070 - Follow-up to fix Windows-only test failure. r=mkmelin

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e52718bc5b79
Follow-up to fix Windows-only test failure. r=mkmelin