2038450 - RecvSetContainerFeaturePolicy missing ownership check

Status: RESOLVED DUPLICATE of bug 2025192

(Core :: DOM: Security, defect)

Description

[jmwebdevelopement]

Steps to reproduce:

While going through ContentParent handlers that accept BrowsingContext parameters i noticed RecvSetContainerFeaturePolicy in dom/ipc/ContentParent.cpp doesnt check whether the sending content process owns the BrowsingContext its targeting

The handler just checks IsNullOrDiscarded and then calls SetContainerFeaturePolicy on whatever BrowsingContext the content process specified:

if (aContainerContext.IsNullOrDiscarded()) {
  return IPC_OK();
}
auto* context = aContainerContext.get_canonical();
context->SetContainerFeaturePolicy(std::move(aContainerFeaturePolicyInfo));

Other handlers in the same file do validate ownership. RecvCreateBrowsingContext checks parent->GetContentParent() != this and returns IPC_FAIL if the content process doesnt own the parent window. RecvSetContainerFeaturePolicy skips this

the container feature policy controls which permissions an iframe gets fullscreen, camera, microphone, geolocation etc it gets picked up by DocumentLoadListener during navigation and Document::InitFeaturePolicy when documents load

I confirmed that child BrowsingContexts are accessible by ID from the parent process the handler resolves whatever BC ID the content process sends. Theres nothing stopping a compromised content process from targeting a BrowsingContext it doesnt own and changing the permissions on a cross-origin iframe

maybe im wrong but the ownership check pattern is there in RecvCreateBrowsingContext and absent here

verified against mozilla-central tip on Firefox ESR 140.10.1

Actual results:

RecvSetContainerFeaturePolicy resolves any BrowsingContext ID the content process sends and calls SetContainerFeaturePolicy on it with no ownership check. peer handler RecvCreateBrowsingContext validates GetContentParent for the same type of operation

Expected results:

RecvSetContainerFeaturePolicy should verify GetContentParent() matches before setting the policy, same as RecvCreateBrowsingContext does for ownership

Comment 1

[Andrew McCreight [:mccr8]]

(In reply to jmwebdevelopement from comment #0)

I confirmed that child BrowsingContexts are accessible by ID from the parent process the handler resolves whatever BC ID the content process sends. Theres nothing stopping a compromised content process from targeting a BrowsingContext it doesnt own and changing the permissions on a cross-origin iframe

Did you actually validate that this is happening? It is supposed to be stopped at the IPC layer by this code.

Comment 2

[jmwebdevelopement]

youre right i missed the IsKnownForMessageReader check in ParamTraits that gates which BrowsingContexts the sender can reference at the IPC layer before the handler runs

my verification was from a parent process context so that deserialization check wouldnt have applied. i should have traced the full IPC path before claiming it was accessible from a content process

does the group-level check fully prevent a compromised content process from targeting a cross-origin BC within the same BrowsingContextGroup? if cross-origin iframes in the same tab share a group that could still be a gap. but if the check covers that then this is fully defended and i missed it

Comment 3

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:freddy, could you have a look please?

For more information, please visit BugBot documentation.