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. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential vulnerability in the Windows implementation of the system-scope Chromium Updater allows unprivileged co-resident users to spoof the Mojo IPC named pipe. Due to a permissive DACL, disabled pipe uniqueness, and weak client verification, an attacker can hijack browser connections. This leads to cross-user update suppression, restricted token disclosure, and internal UI spoofing.

Affected files:

• chrome/updater/ipc/update_service_dialer_win.cc
• chrome/updater/ipc/ipc_security_win.cc
• mojo/public/cpp/platform/named_platform_channel_win.cc
• components/named_mojo_ipc_server/named_mojo_server_endpoint_connector_win.cc
• chrome/updater/ipc/ipc_names_win.cc

Estimated timestamp from git blame: Unknown (Google3 checkout)

Section 1: Summary of the Issue (Meant for Human Triage)

A potential vulnerability on Windows multi-user environments allows an unprivileged, co-resident user to perform cross-user named pipe spoofing against the system-scope Chromium Updater Mojo channel. This occurs because the Chrome browser process connects to a predictable named pipe where the server-side DACL allows Authenticated Users (AU) FILE_CREATE_PIPE_INSTANCE privileges.

Additionally, the legitimate service disables pipe uniqueness enforcement, meaning Windows allows multiple instances of the pipe to coexist. Finally, the client-side authentication in Chrome only validates that the server’s Integrity Level (IL) is greater than or equal to its own. It fails to validate the session ID or SID of the server process.

As a result, a non-admin attacker can pre-create a rogue instance of the \.\pipe\mojo.<ProductFullName>System pipe. When another user starts or runs Chrome at Medium IL, the browser connects to this pipe. Because the attacker’s server also runs at Medium IL, the integrity level check passes, establishing a trusted Mojo connection.

This enables the following impacts:

1. Cross-user update suppression: The attacker can provide fake update replies, deceiving the browser into believing the updater is fully healthy and up-to-date, thereby suppressing critical updates indefinitely (Denial of Service).
2. UI Spoofing: The attacker can send serialized mojom messages that are parsed in the browser process and displayed on internal chrome://updater and chrome://policy diagnostic pages.
3. Limited token disclosure: The client requests the pipe with allow_impersonation = true (mapping to SECURITY_IMPERSONATION). Since standard users lack SeImpersonatePrivilege, Windows restricts the impersonation to Identification level, safely preventing LPE code execution but disclosing the victim’s SID and group memberships to the attacker.

Per Chromium’s severity guidelines, local-LPE vulnerabilities that are restricted to DoS-only (e.g., update suppression) and spoofing on non-primary security surfaces are rated as Low severity (S3).

Section 2: Proof-of-Concept & Detailed Execution Flow

Note: The following steps are potential and suggested; our tooling agent does not have the ability to run code to demonstrate a fully weaponized proof-of-concept, but the logic has been exhaustively verified against the codebase.

1. Attacker Setup and Pipe Squatting

1. The Chromium Updater uses Mojo over named pipes for IPC. The server’s pipe name is predictably generated in chrome/updater/ipc/ipc_names_win.cc:22-31. GetUpdateServiceServerName concatenates the product full name and the scope (System), yielding \.\pipe\mojo.<ProductFullName>System (resolved by GetPipeNameFromServerName in named_platform_channel_win.cc).
2. The legitimate system-scope updater service defines the DACL for this pipe in chrome/updater/ipc/ipc_security_win.cc:32-43 as D:(A;;GA;;;SY)(A;;GA;;;BA)(A;;GRGW;;;AU). The (A;;GRGW;;;AU) ACE grants “Generic Read/Generic Write” to all “Authenticated Users”.
3. In Windows, Generic Write (FILE_GENERIC_WRITE) inherently maps to the FILE_CREATE_PIPE_INSTANCE (0x04) permission, permitting any authenticated user to create additional instances of this pipe.
4. The legitimate updater service configures the Mojo server endpoint to allow multiple clients by setting options.enforce_uniqueness = false; in components/named_mojo_ipc_server/named_mojo_server_endpoint_connector_win.cc:118.
5. Because enforce_uniqueness is false, mojo/public/cpp/platform/named_platform_channel_win.cc:110-113 omits the FILE_FLAG_FIRST_PIPE_INSTANCE flag when calling CreateNamedPipeW.
6. An unprivileged attacker logs into the Windows host, invokes CreateNamedPipeW with the predictable pipe name, and calls ConnectNamedPipe to place their rogue instance into a listening state.

2. Victim Trigger Path

7. A victim user logs into the host and launches Chrome.
8. Background tasks are scheduled via updater::SchedulePeriodicTasks (chrome/browser/chrome_browser_main.cc:1053 -> chrome/browser/updater/scheduler.cc:30).
9. On Windows, DoPeriodicTasks executes CheckUpdaterHealthTask (chrome/browser/updater/scheduler_win.cc:20-23).
10. CheckUpdaterHealthTask calls BrowserUpdaterClient::Create(scope)->GetUpdaterVersion(...) (chrome/browser/updater/check_updater_health_task.cc:109).
11. This initiates a connection: UpdateServiceProxyMojoImpl::GetVersion -> EnsureConnecting -> ConnectMojo (chrome/updater/ipc/update_service_proxy_mojo.cc:191, 445).
12. ConnectMojoImpl (chrome/updater/ipc/update_service_dialer_win.cc:62) first calls DialUpdateService.
13. DialUpdateService makes a blocking COM call (::CoCreateInstance) to activate the legitimate updater service.
14. The legitimate service starts, calls CreateNamedPipeW (succeeding without FILE_FLAG_FIRST_PIPE_INSTANCE), and begins listening. Now, both the attacker’s older instance and the legitimate service’s newer instance are listening.
15. Once CoCreateInstance returns, the browser client calls named_mojo_ipc_server::ConnectToServer, explicitly setting options.allow_impersonation = true and options.verify_server_privilege = true (chrome/updater/ipc/update_service_dialer_win.cc:87-94).
16. The client invokes CreateFileW to connect. The Windows NPFS deterministically routes incoming client connections to the oldest listening instance. Since the attacker’s pipe was created before COM activation, the victim’s connection routes to the attacker’s pipe.

3. Authentication Bypass and Exploitation

17. The browser invokes VerifyServerPrivilege (mojo/public/cpp/platform/named_platform_channel_win.cc:37-57).
18. VerifyServerPrivilege only checks if the server’s Integrity Level is greater than or equal to the client’s (server_token->IntegrityLevel() >= client_token->IntegrityLevel()).
19. Because the attacker and victim both run at Medium IL, the condition evaluates to true. The connection is accepted.
20. The browser client wraps the pipe in a mojo::IsolatedConnection and fuses it to a mojom::UpdateService remote via mojo::FusePipes (chrome/updater/ipc/update_service_proxy_mojo.cc:409-421).
21. The browser sends Mojo requests to the attacker’s rogue server. The attacker responds with arbitrary spoofed Mojo replies (e.g., UpdateState::State::kUpdated).
22. The spoofed responses deceive the browser into believing Chrome is up-to-date, suppressing updates.
23. Additionally, because the client connected with SECURITY_IMPERSONATION, the attacker calls ImpersonateNamedPipeClient. Windows caps this at the “Identification” level due to missing SeImpersonatePrivilege, allowing the attacker to read the token’s properties (SID/group memberships).

Suggested Fix

The Chromium VerifyServerPrivilege logic for the Updater client should be updated to strictly enforce that the named pipe server is running in Session 0, verifying the service’s identity similarly to how Chromoting handles it in remoting/host/chromoting_host_services_client.cc:50-62:

DWORD peer_session_id;
if (!GetNamedPipeServerSessionId(endpoint.platform_handle().GetHandle().get(), &peer_session_id)) { ... }
if (peer_session_id != 0) { ... }

Alternatively, IsConnectionTrusted in chrome/updater/ipc/ipc_security_win.cc could enforce stricter constraints, or the pipe’s DACL could be hardened to restrict AU from possessing FILE_GENERIC_WRITE (specifically FILE_CREATE_PIPE_INSTANCE).

Section 3: Technical Verification Details (Automated Audit Logs - Reviewers may skip this section)

> The vulnerability report correctly identifies a cross-user named pipe spoofing vulnerability in the system-scope Chromium Updater Mojo channel on Windows. > > The root cause involves three factors: > 1. The updater’s named pipe DACL grants Authenticated Users (AU) Generic Write (GW), which maps to FILE_GENERIC_WRITE and crucially includes the FILE_CREATE_PIPE_INSTANCE (0x04) permission. > 2. The legitimate SYSTEM server creates its pipe with enforce_uniqueness = false, meaning it does not set FILE_FLAG_FIRST_PIPE_INSTANCE. > 3. The browser client’s VerifyServerPrivilege function only ensures that server_IL >= client_IL without checking the server’s session ID or SID. > > As a result, any unprivileged user on a multi-user Windows system can create a rogue instance of the predictable \\.\pipe\mojo.<ProductFullName>System pipe. When the victim’s browser process connects, it runs at Medium IL, and the attacker’s rogue server also runs at Medium IL, so the IL check passes. > > Although the client connects with SECURITY_IMPERSONATION, a standard non-admin attacker lacks SeImpersonatePrivilege, meaning Windows silently caps the impersonation token at the Identification level. This prevents full Local Privilege Escalation (LPE) and restricts the attacker to identifying the victim (SID/group disclosure). > > The impact is cross-user update suppression (the attacker can return spoofed UpdateService responses claiming Chrome is up-to-date) and UI spoofing of the internal chrome://updater page. According to Chromium’s severity guidelines, LPE vulnerabilities that are restricted to DoS-only (e.g., update suppression) and spoofing on non-primary security surfaces are rated as Low severity (S3).

Codebase Investigator Output Summaries:

1. IPC Names Validation: chrome/updater/ipc/ipc_names_win.cc:22-43 confirmed entirely predictable. “GetUpdateServiceServerName: Constructed via GetMojoServerName(scope, false) which concatenates PRODUCT_FULLNAME_STRING and either ‘System’ or ‘User’. It does NOT include a version string or a random token.”

2. GetNamedPipeServerSessionId Contrast Validation: remoting/host/chromoting_host_services_client.cc:50-62 implements this securely. “Inside the ConnectToServer function, the client retrieves the peer named pipe server’s session ID and verifies that it is 0… There is no direct call to GetNamedPipeServerSessionId in chrome/updater.”

3. enforce_uniqueness and FILE_FLAG_FIRST_PIPE_INSTANCE: components/named_mojo_ipc_server/named_mojo_server_endpoint_connector_win.cc:118 explicitly sets options.enforce_uniqueness = false;. mojo/public/cpp/platform/named_platform_channel_win.cc:110-113 demonstrates that if enforce_uniqueness is false, FILE_FLAG_FIRST_PIPE_INSTANCE is bypassed.

4. Connection Routing: “Windows deterministically routes incoming client connections to the oldest listening instance of the named pipe.” Since the attacker establishes the pipe before COM triggers the legitimate process, the attacker’s pipe captures the victim’s request.

5. VerifyServerPrivilege Implementation: Confirmed at mojo/public/cpp/platform/named_platform_channel_win.cc:37-57. It retrieves IL via server_token->IntegrityLevel() >= client_token->IntegrityLevel() and performs absolutely no Session or SID verification.

Evaluated with Chrome root at commit: 8c517fbcbb533e59ec9cedac868c8a9bdc30beb2

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

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.