Closed Bug 1860977 (CVE-2024-1936) Opened 11 months ago Closed 6 months ago

PGP encryption can change subject of E-Mail if selecting other mail A while large mail B is decrypting

Categories

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

Thunderbird 115

Tracking

(thunderbird_esr115 fixed, thunderbird124 affected)

RESOLVED FIXED
125 Branch
Tracking Status
thunderbird_esr115 --- fixed
thunderbird124 --- affected

People

(Reporter: 2paso2, Assigned: mkmelin)

References

(Regression)

Details

(Keywords: regression, sec-high, testcase, Whiteboard: [see comment 32, 38])

Attachments

(4 files, 3 obsolete files)

Attached file pics.zip β€”

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

Send 2 E-Mails to myself.
E-Mail A with no encryption
E-Mail B with PGP encryption and 5 MB
Open E-Mail B
While Thunderbird is loading/decrypting click to open E-Mail A

Actual results:

After E-Mail B is encrypted the subject of E-Mail A is permanently changed to the subject of E-Mail B, restarting Thunderbird does not resolve this bug.

Expected results:

Subject of E-Mail A should not change.

typo in Actual results:
it should be after E-Mail B is decrypted

Summary: PGP encryption can changes subject of E-Mail → PGP encryption can change subject of E-Mail
Component: Untriaged → Security: OpenPGP
Product: Thunderbird → MailNews Core
Summary: PGP encryption can change subject of E-Mail → PGP encryption can change subject of E-Mail if selecting other mail A while large mail B is decrypting

I confirm same behavior in User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderbird/115.5.1.

It doesn't matter if the First Message is encrypted or not, nor if the subject of the Encrypted Message is encrypted or not.
Also it doesn't matter if Thunderbird is running with all Add-Ons switched off, nor if it is in Troubleshooting Mode, nor which is the active view, nor if it is clean installation.

Usually this behavior occurs with big enough Encrypted Message witch load slowlier than the smaller ones. I've tested with message with size 8 MB.

This behavior doesn't occur in previous stable versions - 91.13.1 and 102.15.1.

Steps to reproduce:

  • "Message Pane (F8)" switched on
  • Select Encrypted Message
  • While Thunderbird is loading/decrypting the Encrypted Message click to open the First Message

Result - the Subject of First Message is changed with the Subject of the Encrypted Message.

The only thing helping to restore the original subjects is to do "Repair Folder". But after that if the steps above are repeated, the subject is messed up again.
I've tested with folder within IMAP Account and with folder within "Local Folders" - the same behavior occurs.

The following errors are thrown in Error Console:


16:39:59.364 TypeError: currentHeaderData.subject is undefined
setSubject chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:772
modifyMessageHeaders chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1101
processDecryptionResult chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1065
displayStatus chrome://openpgp/content/modules/mimeDecrypt.jsm:667
onStopRequest chrome://openpgp/content/modules/mimeDecrypt.jsm:594
mimeDecrypt.jsm:695:15
16:39:59.364 mimeDecrypt.jsm: caught exception: TypeError
Message: 'currentHeaderData.subject is undefined'
File: chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js
Line: 772
Stack: setSubject@chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:772:5
modifyMessageHeaders@chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1101:26
processDecryptionResult@chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1065:16
displayStatus@chrome://openpgp/content/modules/mimeDecrypt.jsm:667:20
onStopRequest@chrome://openpgp/content/modules/mimeDecrypt.jsm:594:12


Under Windows 10 the JS files are loaded from C:\Program Files\Mozilla Thunderbird\omnia.ja (omni.ja\chrome\openpgp\content\openpgp\ui).

If the Encrypted Message is fully loaded with it's Subject, the Subject of the First Message is shown as it should be. But if you repeat the steps above, the wrong behavior occurs again.

Same here with Thunderbird-115.5.0 on openSUSE-15.5 Linux.

Workaround to fix the subject of an existing mail in an IMAP account:
Use another mail client* to move the mail to another folder.
When Thunderbird finds the mail in another folder it will read the subject again.

*another mail client: second Thunderbird profile / web mail client / different software / mail client on another device

Not fixed in newly updated Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderbird/115.6.0.

Duplicate of this bug: 1873871

A workaround to restore the actual subject of the mail is to "Repair" the folder via Settings of the containing folder -> Repair

I and at least two of my colleagues have the same problem, and it's quite annoying!
Our workaround: DEL and then immediately CTRL-Z to undo the "Delete" restores the correct subject.

Assignee: nobody → mkmelin+mozilla
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Thanks for picking up this patch. Please change gMessage.date = Date.parse(hdr.date) * 1000; to use msg.

This is a regression caused by bug 1803255

A necessary check in function isCurrentMessage(), which was designed to catch this kind of problem, was dropped in this commit:
https://phabricator.services.mozilla.com/D164012

The commit was described as "fix tests", so probably the code that got removed had caused the tests to fail?
It shouldn't have been removed.
I wonder why I wasn't involved in the review of that change...

I suggest that in order to fix this bug, that the old code gets restored.

Keywords: regression
Regressed by: 1803255
Severity: -- → S2
Priority: -- → P1
Target Milestone: --- → 125 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/edd59a219b18
Don't set the subject on the wrong message. r=kaie

Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED

The 115 code is different in multiple ways, so I think we can just let this ride the trains.

I'd prefer to find a way to backport, this seems like a significant regression.

Ok, let me check how that seems.

I wonder if it's sufficient to simply restore the code for the isCurrentMessage() function.

Attached patch 1860977-115-v1.patch (obsolete) β€” β€” Splinter Review

With this patch for 115 (on top of the other queued patches I locally carry for 115), I get successful tests for
mail/test/browser/openpgp
mail/extensions/openpgp/test
mailnews/mime/test/unit/test_openpgp_decrypt.js

Might work since that doesn't have the uri type confusions from bug 1852922.

I'm working on creating a very large local message for reproducing the bug and testing the fix locally (unless you have a better idea).

Please go ahead.

Attached file large-encrypted.gz β€”

This is a compressed mailbox file.

Save.
gzip -d large-encrypted.gz
Then move the file large-encrypted to the $HOME/.thunderbird/some-profile/Mail/Local\ Folders/
directory

The attached patch for the 115 branch works for me.

Without the patch, I can easily reproduce the bug. Start Thunderbird, click the local folder "large encrypted", click the second message that shows with a subject "...", which takes about 2-3 seconds. Immediately after clicking that message, click on the other message in the folder.

Without patch, I can reproduce the bug.

With patch, no bug.

To restart testing, delete the large-encrypted.msf file.

Comment on attachment 9381948 [details] [diff] [review]
1860977-115-v1.patch

Magnus, do you want to mark the backport patch as r+ here, or would you like us to use phabricator?

Comment on attachment 9381948 [details] [diff] [review]
1860977-115-v1.patch

Review of attachment 9381948 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks! r=mkmelin
Attachment #9381948 - Flags: review+

The backport patch doesn't depend on the BB patch, IMHO.
I had independently discovered the removal of the isCurrentMessage() function, and Magnus created the patch based on the old deleted message.
No attribution seems necessary.

I don't see any related failures in a comm-esr115 try build with 1860977-115-v1.patch

I will attach a version 2 with linting fixed.

I will use a local 115.x build with this patch included for a while as my primary Thunderbird, and watch for regressions, prior to requesting 115 approval.

edit:
try build is here:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=9fec4cfba57eb83f37d9d84d8ca1e6811bb83ccc

Attached patch 1860977-115-v2.patch (obsolete) β€” β€” Splinter Review

carrying forward r=mkmelin

Attachment #9381948 - Attachment is obsolete: true
Attachment #9382153 - Flags: review+

There seems to be another way how the broken code could have caused a mess:
If you have multiple tabs open, and one of them is an encrypted message, and then you (re)start Thunderbird, messages will be loading in parallel and corruption may happen.

Duplicate of this bug: 1881689

For everyone affected by this bug, I would like to offer you a test build, a modified version of the 115.x version with the planned fix included, which you could use with your existing Thunderbird settings, to test the fix. I'd appreciate your feedback.

Linux 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/I7JiLB7vRsqAXg9xElLoOg/runs/0/artifacts/public/build/target.tar.bz2

Linux 32bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/L0QwXuqrT4uIvUi8-RciMA/runs/0/artifacts/public/build/target.tar.bz2

Windows 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Wv3dSUSwR9Wplr-Y967UFA/runs/0/artifacts/public/build/target.zip

Windows 32bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ItnE_FoXRaClS0SDUfhnbA/runs/0/artifacts/public/build/target.zip

OSX:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/V-6z0Pw7Rwucw1qBxmSkMg/runs/0/artifacts/public/build/target.dmg

To use, download, and extract the file to a separate directory. Quit your usual Thunderbird. Use a terminal and "cd" to the directory that contains the downloaded build. Run the build from there. I suggest to run from terminal, because then you can easily provide a command line parameter. I suggest to use -P which will allow you to select your existing Thunderbird profile. (Otherwise, the test build might just create a fresh profile with default settings.)

(Using the OSX build is a bit more difficult, as you have to convince the OS to execute the download. I'd have to lookup the details, if necessary.)

Unfortunately we aren't able to automatically repair the existing wrong subject assignments. The fix is limited to avoiding new trouble. It will be necessary that you use the repair folder approach (on each affected folder) to clean up the wrong assignments.

Keywords: testcase
Whiteboard: [see comment 31, 32]

I was told that some users cannot provide their feedback in bugzilla, because this bug is closed.

I'm hereby re-opening the bug temporarily.

If you wanted to provide feedback on the test build, but couldn't, please go ahead and try again. Thanks!

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

I got a report from Al that the JS exceptions from comment 2 are still seen with the experimental build from comment 31.

We have to decide whether we want to attempt a more complete backport, or whether those exceptions are not harmful.

Ok, let's attempt a more complete backport. I'll create a new try build and use phabricator for the updated patch.

Attachment #9382153 - Attachment is obsolete: true

I'm posting what I've wrote to Kai as feedback prior reopening the bug.

I've tested the 64bit test builds of modified 115.x version on Windows 10 x64 and Ubuntu 22.04.4 LTS Jammy.
On both operating systems the subjects are loaded correctly with "Message Pane (F8)" is switched on or if there are Tab opened messages.
Under Windows 10 the error console throw couple of times the following, but I suppose that I've switched between the messages too fast:


17:34:44.575 TypeError: currentHeaderData.subject is undefined
setSubject chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:759
modifyMessageHeaders chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1081
processDecryptionResult chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1045
displayStatus chrome://openpgp/content/modules/mimeDecrypt.jsm:668
onStopRequest chrome://openpgp/content/modules/mimeDecrypt.jsm:595
mimeDecrypt.jsm:700:15
17:34:44.576 mimeDecrypt.jsm: caught exception: TypeError
Message: 'currentHeaderData.subject is undefined'
File: chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js
Line: 759
Stack: setSubject@chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:759:5
modifyMessageHeaders@chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1081:26
processDecryptionResult@chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1045:16
displayStatus@chrome://openpgp/content/modules/mimeDecrypt.jsm:668:20
onStopRequest@chrome://openpgp/content/modules/mimeDecrypt.jsm:595:12

Generally this build works fine for me.
Thank you for your hard work!

Flags: needinfo?(alverb)

I've tested the last 64bit test build (115.8.1 20240225182930I) again on Windows 10 x64 and Ubuntu 22.04.4 LTS Jammy.
With this build the above mentioned errors are hardly reproduceable and occur accidentally.

I've received similar errors just two times:


15:49:20.704 TypeError: currentHeaderData.subject is undefined
setSubject chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:760
modifyMessageHeaders chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1084
processDecryptionResult chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1042
displayStatus chrome://openpgp/content/modules/mimeDecrypt.jsm:668
onStopRequest chrome://openpgp/content/modules/mimeDecrypt.jsm:595
mimeDecrypt.jsm:700:15

15:49:20.704 mimeDecrypt.jsm: caught exception: TypeError
Message: 'currentHeaderData.subject is undefined'
File: chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js
Line: 760
Stack: setSubject@chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:760:7
modifyMessageHeaders@chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1084:26
processDecryptionResult@chrome://openpgp/content/ui/enigmailMsgHdrViewOverlay.js:1042:16
displayStatus@chrome://openpgp/content/modules/mimeDecrypt.jsm:668:20
onStopRequest@chrome://openpgp/content/modules/mimeDecrypt.jsm:595:12


Sometimes when I open a big message with encrypted Subject stored in folder within "Local Folders", the following error is shown in Error Console:


15:39:29.244 rnp_op_verify_execute returned unexpected: 268435456 RNP.jsm:1845:17


All above behavior occurs accidentally only when I'm rapidly switching, opening etc. So I believe that's because some JS are not fully loaded.

Flags: needinfo?(alverb)

Regarding this error: 15:49:20.704 TypeError: currentHeaderData.subject is undefined.

We've wondered why this line got added here:
https://hg.mozilla.org/comm-central/rev/14a2afecab58#l3.57

Al, thanks for testing.

Can you please clarify: Despite the errors on the console, is this bug here correctly fixed in your testing?

Flags: needinfo?(alverb)

Magnus, it might be useful to add the protective change from D202809, to prevent the exception.

I see other places that also check for specific headers being present in currentHeaderData, for example, search for "in currentHeaderData" in mail/base/content/msgHdrView.js

Flags: needinfo?(mkmelin+mozilla)

If D202809 gets r+ from Magnus, I'll merge that little change into the backport-115 revision D202672.

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

Al, thanks for testing.

Can you please clarify: Despite the errors on the console, is this bug here correctly fixed in your testing?

Yes, I think the bug is fixed.
Till now I didn't found any issues or side effects.

You and the other developers can confirm for sure if the coding is OK. :)

Thank you!

Flags: needinfo?(alverb)
Attachment #9387286 - Attachment is obsolete: true

(In reply to Al from comment #45)

Yes, I think the bug is fixed.
Till now I didn't found any issues or side effects.

Thank you!

You and the other developers can confirm for sure if the coding is OK. :)

I wish life was that simple.

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

If D202809 gets r+ from Magnus, I'll merge that little change into the backport-115 revision D202672.

Magnus accepted the change for 115, I've updated the backport revision in phabricator, and I think we're ready to land on 115.

Flags: needinfo?(mkmelin+mozilla)

Comment on attachment 9382500 [details]
Bug 1860977 - Don't set the subject on the wrong message, backport to 115.x. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): 1803255
User impact if declined: wrong functional behavior, false information shown, inconsistent database contents
Testing completed (on c-c, etc.): yes, by volunteers - c-c uses a slightly different patch
Risk to taking this patch (and alternatives if risky): low, because we add more checks, and try to avoid false actions

Attachment #9382500 - Flags: approval-comm-esr115?

Tom, could you please assign a CVE ID ?

Flags: needinfo?(tom)
Keywords: sec-high

Suggested advisory text:

CVE-2024-NNNN:
    title: Leaking of encrypted email subjects to other conversations
    impact: high
    reporter: Several reporters
    description: |
      The encrypted subject of an email message could be incorrectly
and permanently assigned to an arbitrary other email message in
Thunderbird's local cache. Consequently, when replying to the
contaminated email message, the user might accidentally leak the
confidential subject to a third party. While this update fixes the bug
and avoids future message contamination, it does not automatically
repair existing contaminations. Users are advised to use the repair
folder functionality, which is available from the context menu of email
folders, which will erase incorrect subject assignments.
    bugs:
      - url: 1860977
Whiteboard: [see comment 31, 32] → [see comment 32, 38]
Alias: CVE-2024-1936
Flags: needinfo?(tom)

Comment on attachment 9382500 [details]
Bug 1860977 - Don't set the subject on the wrong message, backport to 115.x. r=mkmelin

[Triage Comment]
Approved for esr115

Attachment #9382500 - Flags: approval-comm-esr115? → approval-comm-esr115+

I'm closing this again. Please file a new bug report, if see any related issues, and add a reference to this bug in the new bug.

Status: REOPENED → RESOLVED
Closed: 7 months ago6 months ago
Resolution: --- → FIXED
See Also: → 1892876
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: