Reporter

Description

•

10 months ago

Security Vulnerability Report Draft: Lack of Trust Boundary in GeckoView IPC

Product: Firefox Nightly for Android
csectype- Keywords: csectype-sandbox-escape, csectype-sop, csectype-disclosure
Severity: sec-high (Proposed)

0. Environment and Version Information

Product: Firefox Nightly for Android
Version: 147.0a1
Component: GeckoView :: General
Operating System:
- Target Runtime: Android
- Analysis Environment: Windows
Discovery Method: Manual Static Analysis (Code Review)
Tools Used: Visual Studio Code, grep, manual data flow tracking

1. Summary

Due to a lack of a Trust Boundary in the GeckoView IPC bridge between untrusted content processes and the privileged Android (Java) layer, unauthorized IPC message transmission is possible. This results in a sandbox escape, allowing the content process to perform privileged operations that should be restricted to the parent process.

The GeckoViewActorParent class enables a transparent pass-through between child process actors and the EventDispatcher on the Java side. This class forwards arbitrary JSON-like messages from the content process to the Java layer without performing the following verifications:

Verification of the sender source.
Verification of the message type.
Consistency check of the origin/URI fields against the actual browsing context.

As a result, a compromised content process can achieve the following:

Inject arbitrary GeckoView:* events into the Java layer.
Bypass the assumption that Browser UI and App logic can safely trust origin/URI information coming from GeckoView IPC.
At a minimum, this enables Origin Spoofing on the UI (including the URL bar), History Sniffing, Clipboard manipulation, Drive-by downloads, Origin-spoofed permission requests, and the theft or pollution of usernames and passwords via spoofed origins in Autofill.

In a realistic threat model assuming a content process RCE, this represents a critical weakness in the sandbox/trust boundary between the content sandbox and the privileged Android app.

2. Vulnerable Code Location

2.1 Parent Process JS: `GeckoViewActorParent`

File
mobile/shared/modules/geckoview/GeckoViewActorParent.sys.mjs

Class
GeckoViewActorParent

Method
receiveMessage(aMessage)

Excerpt (Key parts):

    export class GeckoViewActorParent extends JSWindowActorParent {
      static initLogging(aModuleName) {
        const tag = aModuleName.replace("GeckoView", "");
        return GeckoViewUtils.initLogging(tag);
      }

      get browser() {
        return this.browsingContext.top.embedderElement;
      }

      get window() {
        const { browsingContext } = this;
        if (!browsingContext.isContent && browsingContext.window) {
          return browsingContext.window;
        }
        return this.browser?.ownerGlobal;
      }

      get eventDispatcher() {
        return this.window?.moduleManager.eventDispatcher;
      }

      receiveMessage(aMessage) {
        if (!this.window) {
          debug`receiveMessage window destroyed ${aMessage.name} ${aMessage.data?.type}`;
          return null;
        }

        switch (aMessage.name) {
          case "DispatcherMessage":
            return this.eventDispatcher.sendRequest(aMessage.data);
          case "DispatcherQuery":
            return this.eventDispatcher.sendRequestForResult(aMessage.data);
        }

        // Other messages are forwarded to respective GeckoView modules
      }
    }

Findings:

aMessage.data is an object that can be arbitrarily constructed on the child process JSWindowActorChild side.
In the case of "DispatcherMessage" / "DispatcherQuery":
- There is no allow-list check for aMessage.data.type (e.g., "GeckoView:*" strings).
- There is absolutely no integrity verification for uri / origin / principal / node.
- There is no verification of the correspondence between the current browsingContext and the message target.
The data is passed directly to eventDispatcher.sendRequest*, bridging it to the Java EventDispatcher.

2.2 Child Process JS: `GeckoViewActorChild` and `Messaging.sys.mjs`

Files

mobile/shared/modules/geckoview/GeckoViewActorChild.sys.mjs
mobile/shared/modules/geckoview/Messaging.sys.mjs

    import { GeckoViewUtils } from "resource://gre/modules/GeckoViewUtils.sys.mjs";
    import { EventDispatcher } from "resource://gre/modules/Messaging.sys.mjs";

    export class GeckoViewActorChild extends JSWindowActorChild {
      static initLogging(aModuleName) {
        const tag = aModuleName.replace("GeckoView", "") + "[C]";
        return GeckoViewUtils.initLogging(tag);
      }

      actorCreated() {
        this.eventDispatcher = EventDispatcher.forActor(this);
      }
    }

Excerpt from Messaging.sys.mjs:

class ChildActorDispatcher {
  constructor(actor) {
    this._actor = actor;
  }

  sendRequest(aMsg) {
    // Actual code: calls sendAsyncMessage without validation
    this._actor.sendAsyncMessage("DispatcherMessage", aMsg);
  }

  sendRequestForResult(aMsg) {
    // Actual code: calls sendQuery without validation
    return this._actor.sendQuery("DispatcherQuery", aMsg);
  }
}

Findings:

Any JSWindowActorChild can perform the following via EventDispatcher.forActor(this):
- sendRequest({ type: "GeckoView:*", ... })
- sendRequestForResult({ type: "GeckoView:*", ... })
There is no access control or verification for event types here either.

2.3 Java Side: `org.mozilla.gecko.EventDispatcher`

File
mobile/android/geckoview/src/main/java/org/mozilla/gecko/EventDispatcher.java

Excerpt:

    public final class EventDispatcher extends JNIObject {

      private final MultiMap<String, BundleEventListener> mListeners =
          new MultiMap<>(DEFAULT_UI_EVENTS_COUNT);

      public void registerUiThreadListener(
          final BundleEventListener listener, final String... events) {
        synchronized (mListeners) {
          for (final String event : events) {
            mListeners.add(event, listener);
          }
          flush(events);
        }
      }

      @AnyThread
      private void dispatch(
          final String type, final GeckoBundle message, final EventCallback callback) {

        final boolean isGeckoReady;
        synchronized (this) {
          isGeckoReady = isReadyForDispatchingToGecko();
          if (isGeckoReady && mAttachedToGecko && hasGeckoListener(type)) {
            dispatchToGecko(type, message, JavaCallbackDelegate.wrap(callback));
            return;
          }
        }

        dispatchToThreads(type, message, callback, isGeckoReady);
      }

      private boolean dispatchToThreads(
          final String type,
          final GeckoBundle message,
          final EventCallback callback,
          final boolean isGeckoReady) {

        synchronized (mListeners) {
          if (mListeners.containsKey(type)) {
            final EventCallback wrappedCallback = JavaCallbackDelegate.wrap(callback);

            for (final BundleEventListener listener : mListeners.get(type)) {
              ThreadUtils.getUiHandler()
                  .post(() -> listener.handleMessage(type, message, wrappedCallback));
            }
            return true;
          }
        }

        // Subsequent code handles pending queues and error processing
      }
    }

Findings:

The aMessage.data passed from GeckoViewActorParent is packed into a GeckoBundle and decomposed into:
- message (Event body)
- type (Event type string "GeckoView:*")
If a BundleEventListener linked to the type exists, handleMessage(type, message, callback) is called directly on the UI thread.
Even here, neither the validity of type nor the verification of fields inside message is checked.

2.4 Concrete Examples on Android Side: Permission / Autofill

2.4.1 Permission: `GeckoViewPermissionChild` → Java Permission Handler

File
mobile/shared/actors/GeckoViewPermissionChild.sys.mjs

    export class GeckoViewPermissionChild extends GeckoViewActorChild {
      ...

      async promptPermission(aRequest) {
        const types = aRequest.types.QueryInterface(Ci.nsIArray);
        if (types.length !== 1) {
          return { allow: false };
        }

        const perm = types.queryElementAt(0, Ci.nsIContentPermissionType);
        ...

        const principal =
          perm.type === "storage-access"
            ? aRequest.principal
            : aRequest.topLevelPrincipal;

        let allowOrDeny;
        try {
          allowOrDeny = await this.eventDispatcher.sendRequestForResult({
            type: "GeckoView:ContentPermission",
            uri: principal.URI.displaySpec,
            thirdPartyOrigin: aRequest.principal.origin,
            principal: lazy.E10SUtils.serializePrincipal(principal),
            perm: perm.type,
            value: perm.capability,
            contextId: principal.originAttributes.geckoViewSessionContextId ?? null,
            privateMode: principal.privateBrowsingId != 0,
          });

          if (allowOrDeny === Services.perms.ALLOW_ACTION) {
            if (perm.type === "geolocation") {
              const granted = await this.getAppPermissions([
                PERM_ACCESS_FINE_LOCATION,
              ]);
              allowOrDeny = granted
                ? Services.perms.ALLOW_ACTION
                : Services.perms.DENY_ACTION;
            }
          }
        } catch (error) {
          console.error("Permission error:", error);
          allowOrDeny = Services.perms.DENY_ACTION;
        }

        ...
      }
    }

All fields sent here (uri, thirdPartyOrigin, principal, perm, value, contextId, privateMode) are constructed within the child process JS.

On the Java side, Permission-related code in GeckoSession receives the "GeckoView:ContentPermission" event, creates an object equivalent to ContentPermission from the GeckoBundle, and presents it to the UI or passes it to the app's PermissionDelegate (confirmed in code).

2.4.2 Autofill: `GeckoViewAutofill.sys.mjs` → `Autofill.Support`

JS File
mobile/shared/modules/geckoview/GeckoViewAutofill.sys.mjs

    class Autofill {
      constructor(sessionId, eventDispatcher) {
        this.eventDispatcher = eventDispatcher;
        this.sessionId = sessionId;
      }

      start() {
        this.eventDispatcher.sendRequest({
          type: "GeckoView:StartAutofill",
          sessionId: this.sessionId,
        });
      }

      add(node) {
        return this.eventDispatcher.sendRequestForResult({
          type: "GeckoView:AddAutofill",
          node,
        });
      }

      focus(node) {
        this.eventDispatcher.sendRequest({
          type: "GeckoView:OnAutofillFocus",
          node,
        });
      }

      update(node) {
        this.eventDispatcher.sendRequest({
          type: "GeckoView:UpdateAutofill",
          node,
        });
      }

      commit(node) {
        this.eventDispatcher.sendRequest({
          type: "GeckoView:CommitAutofill",
          node,
        });
      }

      clear() {
        this.eventDispatcher.sendRequest({
          type: "GeckoView:ClearAutofill",
        });
      }
    }

Java File
mobile/android/geckoview/src/main/java/org/mozilla/geckoview/Autofill.java
From Autofill.Support's registerListeners / handleMessage:

    public void registerListeners() {
      mGeckoSession
          .getEventDispatcher()
          .registerUiThreadListener(
              this,
              "GeckoView:StartAutofill",
              "GeckoView:AddAutofill",
              "GeckoView:ClearAutofill",
              "GeckoView:CommitAutofill",
              "GeckoView:OnAutofillFocus",
              "GeckoView:UpdateAutofill");
    }

    @Override
    public void handleMessage(
        final String event, final GeckoBundle message, final EventCallback callback) {
      if ("GeckoView:AddAutofill".equals(event)) {
        addNode(message.getBundle("node"), callback);
      } else if ("GeckoView:StartAutofill".equals(event)) {
        start(message.getString("sessionId"));
      } else if ("GeckoView:ClearAutofill".equals(event)) {
        clear();
      } else if ("GeckoView:OnAutofillFocus".equals(event)) {
        onFocusChanged(message.getBundle("node"));
      } else if ("GeckoView:CommitAutofill".equals(event)) {
        commit(message.getBundle("node"));
      } else if ("GeckoView:UpdateAutofill".equals(event)) {
        update(message.getBundle("node"));
      }
    }

Subsequently, Autofill.Session.Node interprets fields included in node such as uuid, bounds, attributes, type, and hint to construct a node tree for Autofill.

3. Threat Model

Attacker:
- An attacker who has already achieved arbitrary code execution (RCE) within the GeckoView content process.
Victim / Target:
- An Android user using Firefox.
Compromised Boundary:
- Untrusted Zone: Sandboxed Content Process.
- Trusted Zone: Parent Process (Android App + GeckoView Java Layer) (Possesses privileges for permission management, autofill, UI display, filesystem, etc.).
- Issue: The Trust Boundary in the IPC bridge (GeckoViewActorParent) between these two zones is not functioning.
Prerequisites:
- The attacker controls native or privileged JS code within the affected content process and can do one of the following:
  - Execute within the context of the relevant JSWindowActorChild.
  - Inject/Modify the Actor's JS module.
- Under this assumption, the attacker can legitimately obtain the EventDispatcher via EventDispatcher.forActor(this).
Attack Vector:
- The attacker constructs arbitrary DispatcherMessage / DispatcherQuery payloads with a chosen type and body, sending them through GeckoViewActorParent to the Java EventDispatcher. These are dispatched as if they were trusted events from Gecko.
Note: This report does not claim that these APIs can be called via Web Content JS alone. The premise is a compromised content process (Post-RCE).

4. Attack Scenario

This section describes a logical reproduction based on the code rather than a fully instrumented end-to-end PoC. It aims to demonstrate the following:

A compromised child process can send arbitrary GeckoView:* events.
These events reach the Java handler without verification by the parent.

Identified Attack Vectors

By exploiting the unvalidated pass-through mechanism of GeckoViewActorParent, the following attacks are possible. These are examples and not exhaustive; any arbitrary GeckoView:* event that a content process can transmit to GeckoViewActorParent can be exploited. Since EventDispatcher.java also transmits to GeckoSession.java without validation, GeckoViewActorParent can abuse functions that should originally be restricted to the child process (e.g., GeckoViewNavigation.sys.mjs).

Permission Prompt Origin Spoofing
- Mechanism: A compromised content process sends a GeckoView:AndroidPermission (or ContentPermission) event as a DispatcherQuery. The Parent Process (GeckoViewActorParent) and EventDispatcher do not verify the authenticity of the sender and pass the uri in the payload directly to the permission handler on the Java side.
- Attack: While executing code on a page under their control, the attacker constructs a payload spoofing the uri of a trusted site (e.g., trusted-bank.example) and requests sensitive permissions like Geolocation.
- Impact: Since the request appears to come from a trusted site on the App UI, the user may mistakenly grant the permission (UI/Origin Spoofing). Additionally, the granted permission state may be incorrectly associated with the spoofed origin.
Autofill Abuse
- Mechanism: Send a GeckoView:AddAutofill event, passing a node object containing a spoofed origin, formId, and field data to the Autofill support on the Java side. The Java side processes this information unconditionally as coming from a trusted Gecko source.
- Attack: The attacker sends fake form information with the origin of a target site (e.g., https://target-site.example), misleading the system into believing the user is currently on that target site.
- Impact: The autofill flow is triggered in the wrong context. Since Firefox's default behavior autofills passwords based on origin, exploiting this allows the attacker to illicitly acquire (steal) the user's stored credentials (ID/Password) for the target site.
URL Bar Spoofing
- Mechanism: GeckoViewActorChild.sys.mjs sends a GeckoView:LocationChange event to GeckoViewActorParent. EventDispatcher.java transmits only the event name and data, such as the URI, to GeckoSession.java.
- Attack: A compromised content process displays a reliable domain like google.com or bank.com in the browser's URL bar while actually displaying the attacker's page.
- Impact: It becomes extremely easy to deceive users into entering credentials on a phishing site.
History Sniffing
- Mechanism: Send a GeckoView:GetVisited event as a DispatcherQuery.
- Attack: Send an arbitrary URL list and retrieve a list of booleans indicating "whether the user has visited that site" from the Java side HistoryDelegate (mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoSession.java#8042-8152).
- Impact: Bypasses the Same-Origin Policy (SOP) and leaks user history.
Drive-by Download
- Mechanism: Send events such as GeckoView:SavePdf or GeckoView:ExternalResponse.
- Attack: Forcefully download and save malicious or unwanted files without explicit user interaction.
- Impact: Consumes storage space or establishes a foothold for malware placement in the download folder.

5. Impact Analysis

At the architectural level, this vulnerability compromises the assumed boundary between:

Untrusted Content Processes
Android App / GeckoView Java Layer (which has access rights to):
- Permission prompts and storage
- Autofill integration
- Other high-privilege UI and system APIs

This vulnerable design allows an attacker to:

Inject arbitrary GeckoView events (GeckoView:*) into the Java layer via IPC without validation by the parent process.
Spoof or confuse origin/URI information in permissions and potentially autofill flows, rendering origin-based policies implemented in the app layer ineffective.
Evade sandbox expectations:
- The Java layer assumes messages coming from GeckoViewActorParent are already trusted and verified, but in reality, they are not.

Even if the ultimate impact were limited to "UI/Origin Spoofing only," this is a significant security issue in the context of a browser. Depending on how the Java side uses unvalidated fields, the impact could expand to:

Incorrect association of permission decisions with origins.
Incorrect attribution of autofill data or unintended disclosure.
Other logic errors in embedded apps that assume trusted input from GeckoView.

Because this bug allows a compromised content process to violate high-level security assumptions within the embedding app, we propose a severity of sec-high.

6. Recommended Fixes and Strategic Recommendations

Based on lessons from Chromium's Mojo IPC security model ("Do not trust the renderer," "Validate all inputs"), we recommend multi-layered mitigation measures.

Validation in GeckoViewActorParent

Change GeckoViewActorParent into a validation layer.
Idea: Before forwarding DispatcherMessage / DispatcherQuery to the EventDispatcher, verify that the origin/URI fields in aMessage.data are consistent with the actual browsing context known to the parent process.

In case of a mismatch, similar to Chromium's mojo::ReportBadMessage, the parent process should treat this as an illegal message and take strong measures (e.g., terminating the violating child process).

7. References

GeckoView / Fenix Source Files (Version 147.0a1 codebase):
- mobile/shared/modules/geckoview/GeckoViewActorParent.sys.mjs
- mobile/shared/modules/geckoview/GeckoViewActorChild.sys.mjs
- mobile/android/geckoview/src/main/java/org/mozilla/gecko/EventDispatcher.java
- mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoSession.java

Flags: sec-bounty?

Daisuke Hatakeyama

Reporter

Comment 1

•

10 months ago

I worked on this vulnerability with [Shota Matsuda/user874there@gmail.com].

Lack of IPC verification in GeckoView allows content processes to send arbitrary messages to the Java layer. This sandbox escape enables origin spoofing, history sniffing, and credential theft by injecting unverified events into privileged UI logic.

Security Vulnerability Report Draft: Lack of Trust Boundary in GeckoView IPC

0. Environment and Version Information

1. Summary

2. Vulnerable Code Location

2.1 Parent Process JS: GeckoViewActorParent

2.2 Child Process JS: GeckoViewActorChild and Messaging.sys.mjs

2.3 Java Side: org.mozilla.gecko.EventDispatcher

2.4 Concrete Examples on Android Side: Permission / Autofill

2.4.1 Permission: GeckoViewPermissionChild → Java Permission Handler

2.4.2 Autofill: GeckoViewAutofill.sys.mjs → Autofill.Support

3. Threat Model

4. Attack Scenario

Identified Attack Vectors

5. Impact Analysis

6. Recommended Fixes and Strategic Recommendations

Validation in GeckoViewActorParent

7. References

Security Approval Request

2.1 Parent Process JS: `GeckoViewActorParent`

2.2 Child Process JS: `GeckoViewActorChild` and `Messaging.sys.mjs`

2.3 Java Side: `org.mozilla.gecko.EventDispatcher`

2.4.1 Permission: `GeckoViewPermissionChild` → Java Permission Handler

2.4.2 Autofill: `GeckoViewAutofill.sys.mjs` → `Autofill.Support`