Closed Bug 1758812 Opened 3 years ago Closed 3 years ago

Ensure that WebVR attack surface isn't exposed over IPC when dom.vr.enabled is false

Categories

(Core :: WebVR, task)

Product:
Core
Component:
WebVR
Type:
task

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1758549

People

(Reporter: jld, Unassigned)

References

Details

I was wondering if turning off WebVR with a pref flip (bug 1750902) was sufficient to prevent a compromised content process from starting the VR process and possibly accessing exposed attack surface.

Looking specifically for exposure of the VR process management code, I found this check in GPUChild::RecvCreateVRProcess, but notice that that tests dom.vr.process.enabled, which controls whether use of WebVR would be remoted to a separate process; that's not the same as dom.vr.enabled and it's still true on Windows. So that allows the GPU process to start the VR process unconditionally (GPUChild is actually the parent), but the GPU process isn't sandboxed yet so that's not a useful attack by itself. I tried tracing the control flow back to the content process, but it's complicated, and I think it might be a good idea to release-assert that dom.vr.enabled is set closer to where it matters (in RecvCreateVRProcess and/or in the VRProcessParent constructor).

Also, there may be other IPC interfaces related to WebVR that should be audited.

Duplicate of bug 1758549?

Flags: needinfo?(jld)

I think this is a dupe. Feel free to reopen if it is not.

Group: core-security → gfx-core-security
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Group: gfx-core-security → core-security-release
Flags: needinfo?(jld)
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.