The compositor process allows uses SurfaceDescriptorRemoteDecoder, which contains a source ID and handle, to link a TextureHost created by a helper process (RDD, media utility, GPU process) to a TextureHost created by a content process during display list building: https://searchfox.org/mozilla-central/rev/48b6992e03fa66f77ac9688ba61c95d31a451bc1/gfx/layers/composite/TextureHost.cpp#340 As you can follow from the code above, we just accept the opaque source/handle without any additional validation. The source ID is merely which utility process created it, not the process that requested it. We decide which VideoBridgeParent that maps to here: https://searchfox.org/mozilla-central/rev/48b6992e03fa66f77ac9688ba61c95d31a451bc1/gfx/layers/composite/GPUVideoTextureHost.cpp#41 The handle is the unique ID associated with that particular texture for that utility process: https://searchfox.org/mozilla-central/rev/077fc34d03b85b09add26b5f99f1a3a3a72c8720/gfx/layers/composite/GPUVideoTextureHost.cpp#47 Nothing stops a compromised content process from using an arbitrary ID. In fact, because we race between the content process creating its own wrapper texture and the utility process creating the actual texture, we gracefully handle the scenario where there is no texture available yet to map to. We should have some sort of token validation here, where the utility process generates namespace IDs for each content process, shares that with the compositor process, and only allows wrapper textures created by the owning content process to wrap the actual texture from the VideoBridge. This would be similar to how we validate graphics resources in the WebRender display pipeline.
Bug 1854669 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The compositor process uses SurfaceDescriptorRemoteDecoder, which contains a source ID and handle, to link a TextureHost created by a helper process (RDD, media utility, GPU process) to a TextureHost created by a content process during display list building: https://searchfox.org/mozilla-central/rev/48b6992e03fa66f77ac9688ba61c95d31a451bc1/gfx/layers/composite/TextureHost.cpp#340 As you can follow from the code above, we just accept the opaque source/handle without any additional validation. The source ID is merely which utility process created it, not the process that requested it. We decide which VideoBridgeParent that maps to here: https://searchfox.org/mozilla-central/rev/48b6992e03fa66f77ac9688ba61c95d31a451bc1/gfx/layers/composite/GPUVideoTextureHost.cpp#41 The handle is the unique ID associated with that particular texture for that utility process: https://searchfox.org/mozilla-central/rev/077fc34d03b85b09add26b5f99f1a3a3a72c8720/gfx/layers/composite/GPUVideoTextureHost.cpp#47 Nothing stops a compromised content process from using an arbitrary ID. In fact, because we race between the content process creating its own wrapper texture and the utility process creating the actual texture, we gracefully handle the scenario where there is no texture available yet to map to. We should have some sort of token validation here, where the utility process generates namespace IDs for each content process, shares that with the compositor process, and only allows wrapper textures created by the owning content process to wrap the actual texture from the VideoBridge. This would be similar to how we validate graphics resources in the WebRender display pipeline.