Closed Bug 2038679 (CVE-2026-8401) Opened 4 months ago Closed 4 months ago

Make the BackupUI and MigrationWizard use remoteTypes

Categories

(Firefox :: Profile Backup, defect)

defect

Tracking

()

RESOLVED FIXED
152 Branch
Tracking Status
firefox-esr115 151+ fixed
firefox-esr140 151+ fixed
firefox150 + fixed
firefox151 + fixed
firefox152 + fixed

People

(Reporter: mccr8, Assigned: mccr8)

References

Details

(Keywords: csectype-sandbox-escape, reporter-external, sec-high, Whiteboard: [adv-main150.0.3+][adv-esr140.11+][adv-esr115.36+])

Attachments

(6 files)

This issue was originally reported by gaddofpwn in bug 2038573. There are a number of interesting issues we may want to fix in that report, so I am splitting off my patch for one issue here. I have marked this as sec-bounty? on their behalf here to ensure we track it.

The basic issue here is that the BackupUI actor can't use remoteTypes because it runs in both the parent process and the privilegedAbout process. Instead, it uses some checks in receiveMessage, but these can be bypassed. BackupUI is very powerful, so if a compromised content process can access it, it can be leveraged into a sandbox escape.

The fix here is to hack up a way to specify a remoteTypes that matches the parent in JSActorProtocol::RemoteTypePrefixMatches and then use that for BackupUI and MigrationUtils (which has the same kind of check).

Flags: sec-bounty?
Assignee: nobody → continuation

BackupUI is not present on ESR115, but MigrationWizard. I'm not sure if it is as dangerous.

Summary: Make the BackupUI use remoteTypes → Make the BackupUI and MigrationWizard use remoteTypes

I've locally run the tests in browser/components/backup/tests/ and browser/components/migration/tests/ and they seem okay. The main risk here is that we run it in a regular content process somehow and we don't test that.

Attached file (secure)

Comment on attachment 9585150 [details]
(secure)

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: The basic issue is rather obvious from the patch, but based on bug 2038573 it does take some cleverness to exploit it, plus you need content process arbitrary code execution to even get at it.
  • 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?: all, yes
  • If not all supported branches, which bug introduced the flaw?: None
  • Do you have backports for the affected branches?: No
  • If not, how different, hard to create, and risky will they be?: Should be trivial. ESR115 will have to drop the BackUI part.
  • How likely is this patch to cause regressions; how much testing does it need?: The risk is that these two actors actually do run in a regular content process in some cases, in which case that specific functionality will be broken.
  • Is the patch ready to land after security approval is given?: Yes
  • Is Android affected?: No
Attachment #9585150 - Flags: sec-approval?

I think these actors are desktop-only but I could be wrong.

Attachment #9585150 - Flags: sec-approval? → sec-approval+

firefox-beta Uplift Approval Request

  • User impact if declined/Reason for urgency: sec-high
  • Code covered by automated testing?: yes
  • Fix verified in Nightly?: no
  • Needs manual QE testing?: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: Might break the backupUI or MigrationWizard functionality if it is used in a different process than we do on testing.
  • String changes made/needed?: none
  • Is Android affected?: no
Attachment #9585210 - Flags: approval-mozilla-beta?
Attached file (secure)

firefox-release Uplift Approval Request

  • User impact if declined/Reason for urgency: sec-high
  • Code covered by automated testing?: yes
  • Fix verified in Nightly?: no
  • Needs manual QE testing?: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: Might break the backupUI or MigrationWizard functionality if it is used in a different process than we do on testing.
  • String changes made/needed?: none
  • Is Android affected?: no
Attachment #9585214 - Flags: approval-mozilla-release?
Attached file (secure)

firefox-esr140 Uplift Approval Request

  • User impact if declined/Reason for urgency: sec-high
  • Code covered by automated testing?: yes
  • Fix verified in Nightly?: no
  • Needs manual QE testing?: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: Might break the backupUI or MigrationWizard functionality if it is used in a different process than we do on testing.
  • String changes made/needed?: none
  • Is Android affected?: no
Attachment #9585237 - Flags: approval-mozilla-esr140?
Attached file (secure)

This folds in the first patch from bug 2005849 which only shuffles code around.

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

Attached file (secure)

This folds in the first patch from bug 2005849 which only shuffles code around.

The BackupUI actor is not present in ESR115, so this only needs to fix
MigrationWizard.

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

Attachment #9585242 - Flags: approval-mozilla-esr115?

firefox-esr115 Uplift Approval Request

  • User impact if declined/Reason for urgency: sec-high
  • Code covered by automated testing?: yes
  • Fix verified in Nightly?: no
  • Needs manual QE testing?: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: Might break the backupUI or MigrationWizard functionality if it is used in a different process than we do on testing.
  • String changes made/needed?: none
  • Is Android affected?: no
Attachment #9585214 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #9585210 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

I got an email from Lando saying "Lando: Landing of D299722 failed!" about half an hour ago, but as far as I can see it has landed on autoland successfully so I'm going to ignore that.

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

I got an email from Lando saying "Lando: Landing of D299722 failed!" about half an hour ago, but as far as I can see it has landed on autoland successfully so I'm going to ignore that.

That's safe to ignore, it was pushed directly since autoland was closed

Yes, you can ignore it. The sheriffs manually landed it because autoland was closed... making the automatic request fail. I tried to cancel the request but that failed as well.

oops didnt see Donal's message. What he said!

Whiteboard: [adv-main150.0.3-]
Group: firefox-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 152 Branch
Whiteboard: [adv-main150.0.3-] → [adv-main150.0.3+]
Alias: CVE-2026-8397
Attachment #9585237 - Flags: approval-mozilla-esr140? → approval-mozilla-esr140+
Alias: CVE-2026-8397 → CVE-2026-8401
Attachment #9585242 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+
Attached file advisory.txt

Updated advisory.txt

Duplicate of this bug: 2005846
QA Whiteboard: [sec] [uplift] [qa-triage-done-c152/b151]
Whiteboard: [adv-main150.0.3+] → [adv-main150.0.3+][adv-esr140.11+][adv-esr115.36+]

This was the main "sandbox escape" fix and CVE for the pwn2own exploit, but we're going to move the bounty request to the reporter's own bug for clarity

Flags: sec-bounty?
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: