2034411 - Parent-process IPC handlers RecvAddCertException and RecvLoadURIExternal lack input validation, allowing a compromised renderer to add arbitrary TLS cert overrides and launch ext

Status: RESOLVED DUPLICATE of bug 2013800

(Firefox :: Untriaged, defect)

Description

[vhoangtran12]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0

Steps to reproduce:

Source code audit of parent-process IPC handlers in dom/ipc/ContentParent.cpp.

• Bug 1: RecvAddCertException (line 6489)

1. A compromised content process calls SendAddCertException() with arbitrary parameters:
   • aCert: attacker-controlled certificate
   • aHostName: any domain (e.g. "google.com")
   • aPort: 443
   • aIsTemporary: false (persistent)
2. The parent process handler at ContentParent::RecvAddCertException (line 6489) passes these directly to nsCertOverrideService::RememberValidityOverride() with no validation.
3. No check that the hostname matches any document loaded by the content process.
4. No ValidatePrincipal() call (compare with RecvAutomaticStorageAccessPermissionCanBeGranted at line 6513 which does validate).
5. The cert override is permanently stored, enabling MitM for the target domain across all future sessions.

• Bug 2: RecvLoadURIExternal (line 4619)

1. A compromised content process calls SendLoadURIExternal() with:
   • uri: any URI (e.g. file://, custom protocol)
   • aTriggeringPrincipal: SystemPrincipalInfo (deserialized to SystemPrincipal by PrincipalInfoToPrincipal in ipc/glue/BackgroundUtils.cpp:53)
2. The parent process handler at ContentParent::RecvLoadURIExternal (line 4619) passes the principal directly to nsExternalHelperAppService::LoadURI() without calling ValidatePrincipal().
3. In LoadURI (uriloader/exthandler/nsExternalHelperAppService.cpp:1092), SystemPrincipal skips all security checks.
4. This allows launching external protocol handlers with full system privileges.

• Evidence of missing validation pattern

Other handlers in the same file correctly validate:

• RecvAutomaticStorageAccessPermissionCanBeGranted (line 6513): calls ValidatePrincipal()
• RecvStorageAccessPermissionGrantedForOrigin (line 6520): calls ValidatePrincipal()

RecvAddCertException and RecvLoadURIExternal do not.

Actual results:

• Bug 1: RecvAddCertException
  The parent process unconditionally accepts the certificate override request from any content process. The attacker-supplied certificate is permanently stored via nsCertOverrideService::RememberValidityOverride() for any arbitrary hostname (e.g. "google.com"), without verifying that the content process has any relationship to that hostname. After this call, all future HTTPS connections to the targeted domain will accept the attacker's certificate, enabling persistent man-in-the-middle attacks that survive browser restarts.

• Bug 2: RecvLoadURIExternal
  The parent process deserializes the attacker-supplied SystemPrincipalInfo into a real SystemPrincipal (via PrincipalInfoToPrincipal in BackgroundUtils.cpp:53) and passes it to nsExternalHelperAppService::LoadURI(). Because SystemPrincipal bypasses all security checks in LoadURI, the compromised content process can trigger external protocol handler launches with full system-level privileges for arbitrary URIs, including file:// and custom protocol schemes.

Expected results:

• Bug 1: RecvAddCertException
  The parent process should validate that the requesting content process is actually loading a document from the specified hostname before allowing a certificate override. At minimum, it should call ValidatePrincipal() as adjacent handlers do (e.g. RecvAutomaticStorageAccessPermissionCanBeGranted at line 6513). Ideally, RecvAddCertException should verify that aHostName matches the origin of a document currently loaded in the requesting content process, and reject the request otherwise.

• Bug 2: RecvLoadURIExternal
  The parent process should call ValidatePrincipal() on the deserialized principal before passing it to LoadURI, rejecting SystemPrincipal from content processes entirely. Content processes should never be able to trigger external handler launches with SystemPrincipal. The handler should either force-downcast the principal to a ContentPrincipal matching the content process's origin, or use a NullPrincipal, ensuring that external handler launches are subject to normal security checks.