2010097 - (CVE-2026-4722) Structured Clone IPC Serialization doesn't perform process validations

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

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

In bug 2008912, it was noticed that we don't do validation that a process should be aware of a specific BCG when receiving a handle for a BrowsingContext/WindowContext from that BCG. While that is being fixed in that bug for normal IPC messages, we also support sending BrowsingContext objects over IPC within ClonedMessageData. Unfortunately for us, unlike normal IPC messages, the data is stored directly inline in the serialized buffer, meaning that we can't easily validate the BCs as they are sent over IPC, because the actual deserialization of the StructuredClone buffer doesn't know the origin process.

Fixing this would probably require some provenance information to be tracked on our StructuredCloneHolder{,Base} instances, which may not be a bad idea to add anyway. I think this could be done using a ThreadsafeContentParentHandle which can be attached to holders created with a DifferentProcess scope. This would then be checked when deserializing the BrowsingContext, recovering the main thread ContentParent for the check (as BrowsingContext can only be deserialized on the main thread)

Comment 1

[Andrew McCreight [:mccr8]]

See bug 2008912 for the explanation of the rating.

Comment 2

[Jens Stutte [:jstutte]]

Fixing this would probably require some provenance information to be tracked ...

Is this a bigger effort? I just wonder if we should keep this on the S2 list of very urgent things.

Comment 3

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

(In reply to Jens Stutte [:jstutte] from comment #2)

Is this a bigger effort? I just wonder if we should keep this on the S2 list of very urgent things.

It's not fully clear how big of an effort this is. It might be as simple as adding an extra parameter to the UnpackClonedMessageData function which indicates the source process which is then added to StructuredCloneData. I can look into it a bit more.

Comment 4

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

Adding bug 2013389 as a dependency, as I ended up doing that large refactoring mostly due to the issues I was running into implementing this, and because the fix will be implemented in terms of it.

Comment 5

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

Attachment: (secure)

This adds some additional tracking to StructuredClone to allow tracking the
origin ChildID which created the StructuredCloneData. This can be used to
perform additional validation on the data before deserializing.

Comment 6

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

Comment on attachment 9544366 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: It's probably not too hard to figure out what the bug is, though it will probably be difficult to figure out how to actually usefully exploit it. Requires privileged JS access in the content process, and it's unclear to what extent this can be used to confuse parent process chrome JS.
• 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?: It will be extremely difficult to backport this fix, as it depends on bug 2013389, which is very large and unlikely to be uplifted.
• How likely is this patch to cause regressions; how much testing does it need?: This may cause some regressions. The patch has not been tested on try yet, and should probably be checked on try before landing. Marking "no" for the next question because of that.
• Is the patch ready to land after security approval is given?: No
• Is Android affected?: Yes

Comment 7

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

Comment on attachment 9544366 [details]
(secure)

I just remembered this is sec-moderate and doesn't need sec-approval, my bad.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/18e4a847d6c9
https://hg.mozilla.org/integration/autoland/rev/db9241824f32
Track origin childID within StructuredCloneData, r=mccr8

Comment 9

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

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

Comment 10

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:nika, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox148 to wontfix.

For more information, please visit BugBot documentation.

Comment 11

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

Unfortunately, we cannot feasibly uplift this patch because of the dependencies.