Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the security team.

Overview: A compromised low-privilege network process in Chrome Remote Desktop can bypass security-critical UI elements in the high-privilege desktop process. By sending a crafted Mojo message with enable_user_interface = false, an attacker can suppress disconnect notifications and local input monitoring, allowing for a stealthy remote takeover.

Affected files:

• remoting/host/me2me_desktop_environment.cc
• remoting/host/desktop_session_agent.cc
• remoting/host/mojom/desktop_session.mojom

Estimated timestamp from git blame: 2025-02-06

Vulnerability Overview

The Chrome Remote Desktop (CRD) service utilizes a multi-process architecture to enforce a security boundary. The Network process, which handles untrusted internet traffic and WebRTC, runs with low privileges (e.g., NT AUTHORITY\LocalService on Windows with a Low Integrity Level). It communicates via a Mojo IPC channel with the Desktop process, which runs with high privileges (System Integrity/elevated user) to capture the screen and inject inputs.

A potential vulnerability exists where the high-privilege Desktop process blindly trusts the enable_user_interface flag provided by the low-privilege Network process during session initialization. An attacker who compromises the Network process can manipulate this flag to disable critical local security features, leading to a stealthy remote takeover of the physical console.

Technical Details

When a remote connection is established, the Network process calls the DesktopSessionAgent::Start Mojo interface in the Desktop process. This call includes a remoting::DesktopEnvironmentOptions struct.

In remoting/host/desktop_session_agent.cc, the Start method accepts these options and passes them unvalidated to the environment factory:

// remoting/host/desktop_session_agent.cc
void DesktopSessionAgent::Start(..., const remoting::DesktopEnvironmentOptions& options, ...) {
  // ...
  delegate_->desktop_environment_factory().Create(..., options, ...);
}

The options are ultimately read by Me2MeDesktopEnvironment::InitializeSecurity:

// remoting/host/me2me_desktop_environment.cc
bool Me2MeDesktopEnvironment::InitializeSecurity(...) {
  // ...
  bool want_user_interface = desktop_environment_options().enable_user_interface();
  if (want_user_interface) {
    // Create the local input monitor.
    local_input_monitor_ = interaction_strategy().CreateLocalInputMonitor();
    // ...
    // Create the disconnect window.
    disconnect_window_ = HostWindow::CreateAutoHidingDisconnectWindow(...);
  }
  return true;
}

Because the Desktop process performs no server-side validation against local machine policies to verify if UI suppression is authorized, a compromised Network process can simply set enable_user_interface to false.

Impact

By bypassing the want_user_interface block, the attacker suppresses:

1. The Disconnect Window: The local user will not see the “Your desktop is shared” notification.
2. The Emergency Hotkey: The Ctrl+Alt+Esc disconnect hotkey is managed by the disconnect window and is never registered.
3. Local Input Monitoring: The “local-wins” policy, which blocks remote input for 2 seconds after local keyboard/mouse activity, is disabled. The attacker can fight the user for input control.

This turns a compromise of an untrusted sandbox into a stealthy, persistent takeover of the local user’s desktop session.

Suggested Reproduction Steps

Note: These are suggested steps based on static analysis, as our tooling cannot execute arbitrary code.

1. Install CRD Me2Me host on a Windows machine where a user is logged in at the physical console.
2. Gain arbitrary code execution in the CRD Network process (running as NT AUTHORITY\LocalService).
3. Construct a remoting::DesktopEnvironmentOptions object in memory with enable_user_interface = false and enable_curtaining = false.
4. Locate the bound mojom::DesktopSessionAgent Mojo remote (managed by DesktopSessionProxy).
5. Invoke DesktopSessionAgent::Start passing the maliciously crafted options struct.
6. Observe that the session connects, but no “Sharing” UI is drawn, Ctrl+Alt+Esc does not disconnect the session, and local mouse movement does not block remote input.

Suggested Fix

The high-privilege Desktop Process should not trust the low-privilege Network Process to enforce policy-based UI constraints.

The DesktopEnvironmentOptions struct should likely be removed from the DesktopSessionAgent::Start Mojo interface entirely. Instead, the high-privilege Daemon or Desktop process should be responsible for resolving the machine’s enterprise policies (e.g., parsing the registry or policy files directly) and explicitly determining whether the UI should be enabled or curtain mode required. If the options must be passed via Mojo, the Desktop process must independently validate the requested options against the actual machine policy before applying them.

Evaluated with Chrome root at commit: ff3d2b74fa39431785bd60e51463b08fcc71ee33

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.