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 Chrome Security team.

Overview: The Chrome Remote Desktop host daemon on Linux fails to clear supplementary groups when dropping privileges for worker processes. Consequently, the network and desktop worker processes inherit the root group (gid 0). This creates a potential sandbox escape and local privilege escalation vector.

Affected files:

• remoting/host/linux/linux_process_launcher_delegate.cc
• remoting/host/daemon_process_linux.cc

Estimated timestamp from git blame: 2026-02-05

Vulnerability Description

There is a potential privilege escalation vulnerability in the Chrome Remote Desktop (CRD) Linux host due to incomplete privilege dropping.

Initial logic and parameters for launching worker processes (both the Network and Desktop workers) are validated. The CRD daemon securely resolves the target unprivileged UIDs and GIDs (such as the _crd_network user) and delegates execution via base::LaunchProcess.

However, inspecting the final credential transition within RunAsUserPreExecDelegate::RunAsyncSafe() (remoting/host/linux/linux_process_launcher_delegate.cc) reveals a critical omission. While the implementation correctly shifts the primary credentials using setgid() and setuid(), it fails to clear the supplementary group list. Standard POSIX processing is applied: because setuid/setgid do not alter supplementary groups, the child processes unconditionally inherit the root daemon’s supplementary groups.

As a result, these supposedly unprivileged worker processes execute with persistent gid 0 (root) membership.

Potential Exploitation Steps

Note: These are suggested/potential steps, as our tooling agent doesn’t yet have the ability to run code to produce a working proof of concept.

1. An attacker achieves arbitrary code execution within the CRD network process (e.g., via a memory safety vulnerability in WebRTC parsing) or the desktop worker process.
2. The attacker executes arbitrary system commands from this compromised context.
3. Because the process retains gid 0 in its supplementary groups, the attacker bypasses the intended sandbox limitations.
4. The attacker successfully reads or writes to sensitive local files, directories, or IPC endpoints restricted to root:root group ownership (e.g., files with 0640 or 0660 permissions), achieving local privilege escalation.

Suggested Fix

Modify RunAsUserPreExecDelegate::RunAsyncSafe() in remoting/host/linux/linux_process_launcher_delegate.cc to explicitly clear or initialize the supplementary groups before calling setuid().

Add a call to setgroups(0, NULL) to completely drop all supplementary groups, or use initgroups() if the unprivileged target user requires specific secondary groups.

Evaluated with Chrome root at commit: 096fc8fdbfacf2546485756d03f160a3d04fcc9b

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.