1500513 - FirstPartyStorageAccessGrantedForOrigin allows a Rogue Content Process to store fraudulent StorageAccessPermission grants

Status: NEW

(Firefox :: Security, enhancement)

Description

[Tom Ritter [:tjr] (OOTO until mid-August)]

In PContent.ipdl, the FirstPartyStorageAccessGrantedForOrigin method accepts a Principal and two Origins that will be used to store StorageAccess Permission.

A Rogue Content Process could call this method with fraudulent values and use it to automatically grant StorageAccess permission, bypassing the user's permission grant.

(This is noted in a comment too:
https://searchfox.org/mozilla-central/rev/9cb3e241502a2d47e2d5057ca771324a446b6695/toolkit/components/antitracking/AntiTrackingCommon.cpp#498 )

We should (at least) validate that the principal and origins make sense (to the extent we can, we can at least check the principal) when we receive this message from the Content Process and ensure they are valid for the content process it originated from. Ideally we can move the permission check into the Parent too, but that may not be possible?

Comment 1

[Andrea Marchesini [:baku]]

We should (at least) validate that the principal and origins make sense (to
the extent we can, we can at least check the principal) when we receive this
message from the Content Process and ensure they are valid for the content
process it originated from. Ideally we can move the permission check into
the Parent too, but that may not be possible?

This bug is definitely valid, but we cannot move the permission check entirely into the parent process.
If the parent process has an actor, corresponding to the document loaded by the content process, we can move part of the login into the parent process, but I don't know if we have such information. The best would be to have 2 actors for the 2 documents: the first-party and the 3rd party contexts. Probably, fission would help here. NI Nika for this.

Comment 2

[Tom Ritter [:tjr] (OOTO until mid-August)]

This is definitely a post-fission task.

Comment 3

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

(In reply to Andrea Marchesini [:baku] from comment #1)

We should (at least) validate that the principal and origins make sense (to
the extent we can, we can at least check the principal) when we receive this
message from the Content Process and ensure they are valid for the content
process it originated from. Ideally we can move the permission check into
the Parent too, but that may not be possible?

This bug is definitely valid, but we cannot move the permission check entirely into the parent process.
If the parent process has an actor, corresponding to the document loaded by the content process, we can move part of the login into the parent process, but I don't know if we have such information. The best would be to have 2 actors for the 2 documents: the first-party and the 3rd party contexts. Probably, fission would help here. NI Nika for this.

The PWindowGlobal actor corresponds to a document loaded by the parent process, so we can likely use that to send the message. Does the principal & URI state in WindowGlobalParent (https://searchfox.org/mozilla-central/rev/952521e6164ddffa3f34bc8cfa5a81afc5b859c4/dom/ipc/WindowGlobalParent.h#72-75,88-89) help out here?

Comment 4

[Chris Peterson [:cpeterson]]

This bug is not a Fission MVP blocker.