2005845 - (CVE-2026-0881) BackupUI actor doesn't check that the messages come from a privileged process

Status: RESOLVED FIXED

(Firefox :: Messaging System, defect)

Description

[Andrew McCreight [:mccr8]]

Bug 1979439 changed the BackupUI actor so that it can be loaded in chrome://browser/content/spotlight.html documents in addition to 3 different about: pages. Looking at those three about pages, I think they are going to either load only in the parent or in a privileged content process, but I don't think anything is stopping spotlight.html from being loaded in any old content process.

I think this means that if a webpage takes over a content process, it could load that document to trigger the starting of the BackupUI actor. I don't know how back that is, but it does look like there are some messages about disabling or changing the password used for the backed up files.

I think the easiest way to deal with this would be to make the receiveMessage method check the remote type of the content process, like the MigrationWizard does.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey Harshit,

Got a moment to patch this one? Be sure to familiarize yourself with https://firefox-source-docs.mozilla.org/bug-mgmt/processes/security-approval.html before you move forward.

Comment 2

[Tom Ritter [:tjr]]

(In reply to Andrew McCreight [:mccr8] from comment #0)

I think the easiest way to deal with this would be to make the receiveMessage method check the remote type of the content process, like the MigrationWizard does.

Definitely the easiest, but long-term it would be really nice to have a more systematic way to address these. I wouldn't implement this based on a single bmo comment, but off the top of my head, I think the best thing would be to require any actor that receives messages from unprivileged processes to be tagged and if an actor without that tag gets instantiated/receives messages from an unprivileged process, it fails in either debug or release mode. (That's the difference between blocklist, which can be forgotten to be tagged, and allowlist which can't be forgotten.)

As a reminder about sec-approval: it will only apply to sec-high bugs, so unless this gets rated that way, you won't need to worry about it.

Comment 3

[Andrew McCreight [:mccr8]]

We've sort of got a bug about being better about requiring remoteTypes: bug 1933540.

Comment 4

[Harshit Sohaney [:hsohaney]]

For now, I'll implement the easy way to avoid any trouble with the backup component. I can't access bug 1933540 but I do like what :tjr is saying about the tags. If that bug doesn't tackle this, we should get a bug open to implement that!
Thanks :mconley for tagging me, I'll get on this!!

Comment 5

[Harshit Sohaney [:hsohaney]]

Attachment: (secure)

Comment 6

[Harshit Sohaney [:hsohaney]]

Comment on attachment 9533210 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Not entirely sure, but nothing is stopping a document from loading the spotlight.html page which should allow the backupUI actors to enable
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: release, beta
• If not all supported branches, which bug introduced the flaw?: Bug 1979439
• Do you have backports for the affected branches?:
• If not, how different, hard to create, and risky will they be?:
• How likely is this patch to cause regressions; how much testing does it need?: Not very likely, the patch just enforces that the backupUI actors are only being messaged from a privileged about context
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: No

Comment 7

[Harshit Sohaney [:hsohaney]]

Note: I wasn't exactly sure what the backports item means, so I've left it blank for now

Comment 8

[Andrew McCreight [:mccr8]]

For the purposes of rating this, I'm trying to figure out what capabilities the BackupUI actor has.

• Restore a profile from an attacker specified file. This could potentially be very bad, but it looks like the file name gets passed in to IOUtils.getFile(), so it does have to be a real file on the file system. Maybe an attacker could trigger a download (because we don't ask) and then somehow figure out what the save path is, and then use that? Okay, I guess that seems bad enough to mark this sec-high.
• Via the BackupService:StateUpdate event or a RequestState message, it can get a copy of the BackupService state, which looks like it contains a few paths on the local file system.
• It can create or schedule a backup. The scheduled backup can be done with an attacker-controlled password.
• It can pop up a file picker, then send the path to the child if the user picks something.
• Scheduled backups can be disabled.
• Retrieve information about an attacker-specified backup file, like the app version, but it doesn't look to be sent to the child.
• Enable encryption for the profile backup using an attacker controlled password. Good for a "ransomware" scenario, but that kind of only matters if the attack could corrupt the profile so you need the backup so I think that doesn't matter.
• Disable encryption for the profile. It doesn't look like the attacker needs to supply the current password. Doesn't seem too terrible, but I guess it could be useful in concert with some other local attack.

Comment 9

[Harshit Sohaney [:hsohaney]]

That first scenario sounds pretty doable and bad!!! I didn't really think of that, what are the next steps here? I haven't worked on a sec bug before!

Comment 10

[Andrew McCreight [:mccr8]]

(In reply to Harshit Sohaney [:hsohaney] from comment #9)

That first scenario sounds pretty doable and bad!!! I didn't really think of that, what are the next steps here? I haven't worked on a sec bug before!

I think the fix you have here should prevent it, so given that you wrote the patch and put it up for sec-approval, you've done everything for now.

Comment 11

[Tom Ritter [:tjr]]

Comment on attachment 9533210 [details]
(secure)

Approved to land and request uplift

Comment 12

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Possible security issue
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Try to receiveMessage into the backupUI actors in a non about page. This patch should not allow that.
• Risk associated with taking this patch: low
• Explanation of risk level: Adds a check to ensure we are receiving messages from a privileged page, this should not effect any functionality unless the spotlight is opened in an unprivileged context.
• String changes made/needed: No
• Is Android affected?: no

Comment 13

[Harshit Sohaney [:hsohaney]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D276562

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a38fadbba8c4
https://hg.mozilla.org/integration/autoland/rev/bcb2f08f31bc
Add a check to ensure that the spotlight is loaded from the about page. r=mconley

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/5cd7ee930b78
https://hg.mozilla.org/integration/autoland/rev/a77e011fba00
Revert "Bug 2005845 - Add a check to ensure that the spotlight is loaded from the about page. r=mconley" for causing bc failures on browser_preferences.js

Comment 16

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

• Push with failures
• Failure log

[task 2025-12-17T23:09:53.852+00:00] 23:09:53     INFO - TEST-PASS | browser/components/profiles/tests/browser/browser_preferences.js | The profiles note is hidden - 
[task 2025-12-17T23:09:53.853+00:00] 23:09:53     INFO - Buffered messages finished
[task 2025-12-17T23:09:53.855+00:00] 23:09:53     INFO - TEST-UNEXPECTED-FAIL | browser/components/profiles/tests/browser/browser_preferences.js | A promise chain failed to handle a rejection: can't access property "isInProcess", this.browsingContext.currentWindowGlobal is null - stack: receiveMessage@resource:///actors/BackupUIParent.sys.mjs:129:7
[task 2025-12-17T23:09:53.855+00:00] 23:09:53     INFO - JSActor query*handleEvent@resource:///actors/BackupUIChild.sys.mjs:31:12
[task 2025-12-17T23:09:53.855+00:00] 23:09:53     INFO - connectedCallback@chrome://browser/content/backup/backup-settings.mjs:116:10
[task 2025-12-17T23:09:53.855+00:00] 23:09:53     INFO - init@chrome://browser/content/preferences/preferences.js:319:18
[task 2025-12-17T23:09:53.855+00:00] 23:09:53     INFO - initializeCategories@chrome://browser/content/preferences/findInPage.js:130:18
[task 2025-12-17T23:09:53.855+00:00] 23:09:53     INFO - init/</<@chrome://browser/content/preferences/findInPage.js:78:47
[task 2025-12-17T23:09:53.855+00:00] 23:09:53     INFO - requestIdleCallback handler*init/<@chrome://browser/content/preferences/findInPage.js:78:16
[task 2025-12-17T23:09:53.855+00:00] 23:09:53     INFO - EventListener.handleEvent*init@chrome://browser/content/preferences/findInPage.js:73:14
[task 2025-12-17T23:09:53.855+00:00] 23:09:53     INFO - init_all@chrome://browser/content/preferences/preferences.js:388:22
[task 2025-12-17T23:09:53.855+00:00] 23:09:53     INFO - EventListener.handleEvent*@chrome://browser/content/preferences/preferences.js:338:1

Comment 17

[Harshit Sohaney [:hsohaney]]

I have a fix up for review, thanks for the log!!

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/8c22be6bad0c
https://hg.mozilla.org/integration/autoland/rev/f79727e05475
Add a check to ensure that the spotlight is loaded from the about page. r=mconley

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b64f5ef67623
https://hg.mozilla.org/integration/autoland/rev/18d45c44261d
Revert "Bug 2005845 - Add a check to ensure that the spotlight is loaded from the about page. r=mconley" for causing bc failures in browser_sanitizeOnShutdown_migration.js

Comment 20

[Cristian Tuns]

Backed out for causing bc failures

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | browser/base/content/test/sanitize/browser_sanitizeOnShutdown_migration.js | A promise chain failed to handle a rejection: can't access property "isInProcess", this.browsingContext.currentWindowGlobal is null - stack: receiveMessage@resource:///actors/BackupUIParent.sys.mjs:129:7

And also : https://treeherder.mozilla.org/logviewer?job_id=540754090&repo=autoland&task=aAScn8fsSGO7xZ6Ket1RWA.0

And : https://treeherder.mozilla.org/logviewer?job_id=540757109&repo=autoland&task=KhLA_6n-RiiVCTNk457FIA.0

Comment 21

[Harshit Sohaney [:hsohaney]]

so sorry this keeps failing, I'm not sure how to do all the possible tests locally since i can't push this onto try, does anyone have any tips? This failure seems to be coming from outside of the component.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

I think you're fine pushing it to Try at this point. The code change is effectively already public anyway from the times it was on autoland, so a Try push won't be divulging anything new.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/6e74e112384a
https://hg.mozilla.org/integration/autoland/rev/6d0575abd8dc
Add a check to ensure that the spotlight is loaded from the about page. r=mconley

Comment 24

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/mozilla-central/rev/6d0575abd8dc

Comment 25

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Possible security issue
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Try to receiveMessage into the backupUI actors in a non about page. This patch should not allow that.
• Risk associated with taking this patch: low
• Explanation of risk level: Adds a check to ensure we are receiving messages from a privileged page, this should not effect any functionality unless the spotlight is opened in an unprivileged context.
• String changes made/needed: No
• Is Android affected?: no

Comment 26

[Harshit Sohaney [:hsohaney]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D276562

Comment 27

[Carmen Fat [:cfat] - Ecosystem QA]

Could you please provide detailed testing instructions to help us verify this change? Since this is a security-related issue, we want to ensure our validation is thorough and that we don't miss anything critical. Thank you.

Comment 28

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/bd83a78bf512
https://hg.mozilla.org/releases/mozilla-beta/rev/9b5a033185c2

Comment 29

[Harshit Sohaney [:hsohaney]]

Hmmm I'm not entirely sure how to embed the spotlight in a content page, :mccr8 could you help us out here?

Comment 30

[Andrew McCreight [:mccr8]]

Sorry for the slow reply. I'm not sure either. It is probably fine to skip the verification here...

Comment 31

[Carmen Fat [:cfat] - Ecosystem QA]

Removing the qe-verify+ flag based on comment 30.

Please let me know if anything changes in regards to this issue not needing QA verification. Thank you.