2038595 - Web Locks RecvPLockManagerConstructor does not validate content principals against the sending content process, allowing cross-origin lock namespace manipulation after content-process compromise

Status: RESOLVED DUPLICATE of bug 2054671

(Core :: DOM: Core & HTML, defect)

Description

[Attila Csatadi]

Attachment: MOZILLA_LOCKMANAGER_SUPPORTING_PROOF_CARD_FINAL.md

Affected component:
Firefox / Core / Web Locks / PLockManager parent actor

Summary:
BackgroundParentImpl::RecvPLockManagerConstructor(...) appears to reject a system principal coming from a content process, but it does not appear to validate content principals against the sending content process. The resulting LockManagerParent is keyed by the supplied principal, so a compromised content process can attach a PLockManager to another origin's Web Locks namespace.

This is not a normal web-content JavaScript-only attack and it is not a sandbox escape. The precondition is a compromised content process / renderer-RCE-capable primitive that can send raw PBackground IPC. The impact is bounded: cross-origin Web Locks namespace manipulation, denial-of-service against predictable victim lock names, and limited lock-state disclosure through query().

Affected path:

• ipc/glue/BackgroundParentImpl.cpp
  • BackgroundParentImpl::RecvPLockManagerConstructor(...)
• dom/locks/LockManagerParent.cpp
  • LockManagerParent::LockManagerParent(...)
  • RecvPLockRequestConstructor(...)
  • RecvQuery(...)
  • lock grant / queue processing
• dom/locks/LockManager.cpp
  • legitimate caller sends the current global/client principal

Observed validation gap:

RecvPLockManagerConstructor(...) appears to contain this guard:

if (aPrincipalInfo->IsSystemPrincipal() && BackgroundParent::IsOtherProcessActor(this)) {
  return IPC_FAIL_NO_REASON(this);
}
return IPC_OK();

This rejects system principals from content processes, but I do not see a corresponding check for content principals. I do not see the parent verify that the supplied content principal is an origin the sending content process is allowed to act for.

The LockManagerParent then uses the supplied principal to select the Web Locks namespace. All actors with the same principal share the corresponding managed lock state.

Attack sketch:

Precondition:
The attacker has compromised a content process that can send raw PBackground IPC.

Steps:

1. From the compromised attacker process, send PLockManagerConstructor with a forged victim-origin content principal, for example https://victim.example/.
2. The parent creates or attaches a LockManagerParent to the victim origin's Web Locks namespace.
3. The attacker sends a lock request for a predictable victim lock name, for example sync-mutex or another app/library-defined lock name.
4. If granted, the attacker holds the exclusive lock and refuses to release it.
5. Victim pages using the same named lock are blocked while the attacker actor remains alive.
6. The attacker can also call query() on the victim namespace and receive the held/pending lock names, modes, and client IDs.

Claimed impact:

A compromised content process can manipulate another origin's Web Locks namespace.

Potential impact:

• denial-of-service against victim apps that coordinate work using predictable Web Locks names;
• limited state disclosure via lock names and pending/held lock state;
• cross-origin / Fission-isolation violation, but bounded compared with storage or cookie disclosure issues.

Important limitations:

• This is not a standalone web JavaScript exploit.
• This requires a compromised content process or equivalent raw-IPC primitive.
• This is not claimed as a sandbox escape.
• The DoS requires predictable victim lock names.
• The query() leak is limited to lock names, modes, and client IDs.

Suggested fix:

When RecvPLockManagerConstructor(...) receives a content principal from a content process, validate that principal against the sending content process before constructing or binding the LockManagerParent.

Suggested shape:

1. Obtain the sending content process handle from the PBackgroundParent actor.
2. Validate that the supplied principal can be loaded by / is authorized for that process.
3. Reject mismatches before the lock manager actor becomes usable.
4. Consider deriving the namespace principal from parent-authoritative client/document metadata rather than trusting a content-supplied principal.

Reporter notes:

I am reporting this privately as a security-sensitive bug.

I am not claiming exploitation in the wild.

I am not claiming a standalone sandbox escape.

I can help develop a targeted Mozilla test / IPC-level reproducer if the team can confirm the preferred harness style.