1958350 - (CVE-2025-4083) Process isolation bypass using javascript URI links in cross origin frames

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect, P2)

Description

[Nika Layzell [:nika] (ni? for response)]

Bug 1956954 revealed a new way in which we could end up loading cross-origin content in the wrong content process on Desktop Firefox. This is not a new bug introduced by bug 1665474, but rather an existing issue (since the release of Fission) which this new crash made visible. (In a way, versions with bug 1665474 are resistant to the bug, as the crash prevents it from happening in most cases).

Specifically, if you command/control-click on a javascript: link within a cross-origin iframe, frontend will end up creating the document to run that javascript: URI in within the process of the toplevel document in that tab, rather than the cross-origin iframe. Unlike normal navigations, javascript: URI loads do not process switch within Gecko, meaning the JS payload is executed within the process selected by frontend.

---

The following is a fairly minimal STR, though it will require referencing about:processes to confirm the remote types:

<!-- localhost:8000/index.html -->
<iframe src="http://127.0.0.1:8000/iframe.html"></iframe>
<!-- 127.0.0.1:8000/iframe.html -->
<a href="javascript:alert(1)">ctrl-click me</a>

If you ctrl-click the inner link, the alert(1) JS code will be executed with the principal of http://127.0.0.1:8000, but within the http://localhost:8000 content process.

---

This bug is caused by frontend JS code not being able to select a remote type based solely off of a javascript: URI, so falling back to the default. In this case, the default is derived from the openerBrowser, which is the remote type of the toplevel document in the opening browser: https://searchfox.org/mozilla-central/rev/7014a821bb4689deb04f647a153a6db10e580a00/browser/components/tabbrowser/content/tabbrowser.js#3312-3316. Because we're actually opening a link from an iframe, this ends up being incorrect.

There is also a second codepath which is relevant here, which is when opening a new window. In this case, the fallback remote type will be DEFAULT_REMOTE_TYPE (https://searchfox.org/mozilla-central/rev/7014a821bb4689deb04f647a153a6db10e580a00/browser/components/tabbrowser/content/tabbrowser.js#504), meaning the javascript: URI will end up running in a "web" process for all origins.

The simplest approach for these callsites where we're creating a new browser is likely to instead use the triggeringRemoteType which was added in bug 1538028 as the fallback remote type when it is available, to ensure that if we cannot determine the remote type, we use the remote type of the process which requested the navigation. I believe this should have the correct behaviour for javascript: URI loads.

Comment 1

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1958350 - Part 1: Fall back to the triggeringRemoteType when available for initial browser remoteType, r=gijs!

Comment 2

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1958350 - Part 2: Add test for subframe content area clicks, r=gijs!

Comment 3

[Dianna Smith [:diannaS]]

:nika does this fix the crash in bug 1956954 as well?

Comment 4

[Nika Layzell [:nika] (ni? for response)]

(In reply to Dianna Smith [:diannaS] from comment #3)

:nika does this fix the crash in bug 1956954 as well?

That is the intention, though I’d also like to land some extra checks in that bug after this lands.

Comment 5

[Nika Layzell [:nika] (ni? for response)]

Comment on attachment 9477099 [details]
Bug 1958350 - Part 1: Fall back to the triggeringRemoteType when available for initial browser remoteType, r=gijs!

Security Approval Request

• How easily could an exploit be constructed based on the patch?: From the tests it is probably pretty straightforward to determine how to exploit this particular sandbox escape bug.

For this reason it might make sense to land the primary part of the patch separately, which could probably be reversed but would be slightly less easy.

• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes
• 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
• 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?: I believe this patch should apply to other branches with relatively minimal rebasing, though the changes required for ESR 115 would probably be more substantial (as tabbrowser has been refactored a bit since then).

The core parameter used here (triggeringRemoteType) appears to be available on all branches.

• How likely is this patch to cause regressions; how much testing does it need?: The core patch should be unlikely to cause regressions, as it is changing the process prediction algorithm when creating new pop-up windows to be more accurate.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: No

Comment 6

[Daniel Veditz [:dveditz]]

Comment on attachment 9477099 [details]
Bug 1958350 - Part 1: Fall back to the triggeringRemoteType when available for initial browser remoteType, r=gijs!

sec-approval+ , a=dveditz

April 18 (Friday) morning we'll start the build for the last 138 beta. The patch seems safe enough for uplift in that time—can you get it in by then? If not we should hold off landing until the 140 cycle and uplift to 139 in beta.

Comment 7

[Daniel Veditz [:dveditz]]

Please wait until after the release to land the test.

Comment 8

[Nika Layzell [:nika] (ni? for response)]

Comment on attachment 9477099 [details]
Bug 1958350 - Part 1: Fall back to the triggeringRemoteType when available for initial browser remoteType, r=gijs!

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Potential cross-origin information leaks in a compromised content process (able to run arbitrary JS in the wrong content process).
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Fairly straightforward changes to frontend code. Automated tests have been written, but are not being landed with the initial sec bug landing.
• String changes made/needed: None
• Is Android affected?: No

Comment 9

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1958350 - ESR115: Fall back to the triggeringRemoteType when available for initial browser remoteType, r=gijs!

Comment 10

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1958350 - ESR128: Fall back to the triggeringRemoteType when available for initial browser remoteType

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a8155d8bd280
Part 1: Fall back to the triggeringRemoteType when available for initial browser remoteType, r=Gijs,tabbrowser-reviewers,mconley

Comment 12

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

https://hg.mozilla.org/mozilla-central/rev/a8155d8bd280

Comment 13

[Dianna Smith [:diannaS]]

Comment on attachment 9477099 [details]
Bug 1958350 - Part 1: Fall back to the triggeringRemoteType when available for initial browser remoteType, r=gijs!

Approved for 138.0rc1

Comment 14

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/ad6296e4ca43

Comment 15

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: Potential cross-origin information leaks in a compromised content process (able to run arbitrary JS in the wrong content process).
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: N/A
• Risk associated with taking this patch: Low
• Explanation of risk level: Fairly straightforward changes to frontend code. Automated tests have been written, but are not being landed with the initial sec bug landing.
• String changes made/needed: None
• Is Android affected?: no

Comment 16

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/cce4f7f8352e

Comment 17

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: Potential cross-origin information leaks in a compromised content process (able to run arbitrary JS in the wrong content process).
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: N/A
• Risk associated with taking this patch: Low
• Explanation of risk level: Fairly straightforward changes to frontend code. Automated tests have been written, but are not being landed with the initial sec bug landing.
• String changes made/needed: None
• Is Android affected?: no

Comment 18

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/b9f25b5c8d1a

Comment 19

[Jason Kratzer [:jkratzer]]

Attachment: advisory.txt

Comment 20

[Daniel Veditz [:dveditz]]

Tom rightly points out that sec-moderate was a more appropriate rating: The target site has to frame a page from another site with a malicious javascript: link, the potential victim has to ctrl-click on the framed link. The script still runs in the correct origin so the attacker has to combine that with another attack (spectre-like, or RCE JS bug) to gain anything by this.

Comment 21

[BugBot [:suhaib / :marco]]

27 days ago, dveditz placed a reminder on the bug using the whiteboard tag [reminder-test 2025-05-15] .

nika, please refer to the original comment to better understand the reason for the reminder.

Comment 22

[Nika Layzell [:nika] (ni? for response)]

queued the test for landing.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2cdd7b6528bc
Part 2: Add test for subframe content area clicks, r=Gijs,frontend-codestyle-reviewers

Comment 24

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

https://hg.mozilla.org/mozilla-central/rev/2cdd7b6528bc