1956398 - (CVE-2025-2857) Investigate Windows Chromium pseudo handle issue

Status: RESOLVED FIXED

(Core :: IPC, defect, P1)

Description

[Andrew McCreight [:mccr8]]

Chromium patched a zero-day today with this odd description:

Incorrect handle provided in unspecified circumstances in Mojo on Windows.

There's a blog post about it by the people who found it which doesn't have too many details but it does say:

The vulnerability CVE-2025-2783 really left us scratching our heads, as, without doing anything obviously malicious or forbidden, it allowed the attackers to bypass Google Chrome’s sandbox protection as if it didn’t even exist. The cause of this was a logical error at the intersection of Google Chrome’s sandbox and the Windows operating system.

The patch for the issue is here. The patch summary is:

Avoid receiving or sending sentinel handle values.
These values can be misinterpreted by OS functions, so avoid sending or receiving them over IPCZ.

The patch seems to take an existing concept of a "pseudo handle" in their IPC layer, and add checks for it to more places.

While we do use Mojo, the patches are for ipcz, which is newer than what we are using, so it doesn't directly apply, but we should figure out if we're affected by a similar issue. I'll try to look more tomorrow.

Comment 1

[Yannis Juglaret [:yannis]]

We have reasonable suspicions that we could be vulnerable to a similar attack through Channel::ChannelImpl::AcceptHandles. Although we are not sure exactly of the details of the attack, it seems rather straightforward to write the patch and I will do that.

Comment 2

[Andrew McCreight [:mccr8]]

This chromium-review link has a few public review comments. They also wrote and abandoned a unit test after failing to make it work, but it also might explain what is going on.

Comment 3

[Andrew McCreight [:mccr8]]

Here's a warning from MS that was linked from a related Chromium issue:

A process that has some of the access rights noted here can use them to gain other access rights. For example, if process A has a handle to process B with PROCESS_DUP_HANDLE access, it can duplicate the pseudo handle for process B. This creates a handle that has maximum access to process B.

Comment 4

[Yannis Juglaret [:yannis]]

Attachment: Bug 1956398 - Avoid duplicating pseudo-handles in ipc_channel_win.cc.

Comment 5

[Andrew McCreight [:mccr8]]

I'm looking over the DuplicateHandle calls outside of ipc/ that are not simply GetCurrentProcess() to GetCurrentProcess() (which I'm guessing should be okay). I guess the relevant one is remote-to-current so I'll only put those here.

• FileSystemPolicy::SetInformationFileAction: from client_info.process to current process.
• GetSharedMemoryRegion: from client_info.process to current process.
• RegistryDispatcher::NtCreateKey and RegistryDispatcher::NtOpenKey.
• SignedDispatcher::CreateSection
• CrashGenerationServer::PrepareReply. 3 calls.
• CreateScopedPrintHandle from content_analysis_sdk.

Comment 6

[Tom Ritter [:tjr] (OOTO until April)]

(In reply to Andrew McCreight [:mccr8] from comment #5)

I'm looking over the DuplicateHandle calls outside of ipc/ that are not simply GetCurrentProcess() to GetCurrentProcess() (which I'm guessing should be okay). I guess the relevant one is remote-to-current so I'll only put those here.

The concern would be if any of those handles would be either:

• If the parent process operates on the handle (which could be a handle to itself) in a way that makes the process unsafe in some way. I don't know what this could be but as a real strawman example "Make the target of this handle open-able by all processes" (I don't even know if you can do that.)
• If the parent process passes the handle back to the child

• FileSystemPolicy::SetInformationFileAction: from client_info.process to current process.

Confusingly this seems like a look between SetInformationFileAction and NtSetInformationFile but it looks okay.

Comment 7

[Tom Ritter [:tjr] (OOTO until April)]

• RegistryDispatcher::NtCreateKey and RegistryDispatcher::NtOpenKey.

This is okay.

• SignedDispatcher::CreateSection

This is concerning...

• CrashGenerationServer::PrepareReply. 3 calls.

This is okay

Comment 8

[Tom Ritter [:tjr] (OOTO until April)]

• SignedDispatcher::CreateSection

CreateSection will fail with STATUS_OBJECT_TYPE_MISMATCH so it's alright

• CreateScopedPrintHandle from content_analysis_sdk.

Weird, but safe. Could try to print the parent process to a file.

Comment 9

[Tom Ritter [:tjr] (OOTO until April)]

Comment on attachment 9474767 [details]
Bug 1956398 - Avoid duplicating pseudo-handles in ipc_channel_win.cc.

Approved to land

Comment 10

[Andrew McCreight [:mccr8]]

Marking this sec-critical because Nika thinks this could be exploited in Firefox via postMessage to your own BrowsingContext.

Comment 11

[Andrew McCreight [:mccr8]]

Attachment: Bug 1956398 - Avoid duplicating pseudo-handles in ipc_channel_win.cc.

Original Revision: https://phabricator.services.mozilla.com/D243135

Comment 12

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: sec-critical
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: none
• Risk associated with taking this patch: low
• Explanation of risk level: behavior should only change in exploited situation, plus we're cribbing off of a Chromium patch that has been deployed already
• String changes made/needed: none
• Is Android affected?: yes

Comment 13

[Andrew McCreight [:mccr8]]

Attachment: Bug 1956398 - Avoid duplicating pseudo-handles in ipc_channel_win.cc.

Original Revision: https://phabricator.services.mozilla.com/D243135

Comment 14

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: sec-critical
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: none
• Risk associated with taking this patch: low
• Explanation of risk level: behavior should only change in exploited situation, plus we're cribbing off of a Chromium patch that has been deployed already
• String changes made/needed: none
• Is Android affected?: yes

Comment 15

[Andrew McCreight [:mccr8]]

Attachment: Bug 1956398 - Avoid duplicating pseudo-handles in ipc_channel_win.cc.

Original Revision: https://phabricator.services.mozilla.com/D243135

Comment 16

[Phabricator Automation]

release Uplift Approval Request

• User impact if declined: sec-critical
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: none
• Risk associated with taking this patch: low
• Explanation of risk level: behavior should only change in exploited situation, plus we're cribbing off of a Chromium patch that has been deployed already
• String changes made/needed: none
• Is Android affected?: yes

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/33af93ce40ec
Avoid duplicating pseudo-handles in ipc_channel_win.cc. r=nika a=RyanVM

Comment 18

[Andrew McCreight [:mccr8]]

I said Android was affected in all of my uplift requests, but actually this is Windows-only. Sorry.

Comment 19

[Pulsebot]

FIREFOX_136_0_X_RELBRANCH revision https://hg.mozilla.org/releases/mozilla-release/rev/338dbe214b58

Comment 20

[Pulsebot]

FIREFOX_ESR_128_8_X_RELBRANCH revision https://hg.mozilla.org/releases/mozilla-esr128/rev/d156a4452c9d

Comment 21

[Pulsebot]

FIREFOX_ESR_115_21_X_RELBRANCH revision https://hg.mozilla.org/releases/mozilla-esr115/rev/5ee62877b9cf

Comment 22

[Pulsebot]

default (137.0) revision https://hg.mozilla.org/releases/mozilla-release/rev/618475773011

Comment 23

[Pulsebot]

default (128.9esr) revision https://hg.mozilla.org/releases/mozilla-esr128/rev/3aaf665616b3

Comment 24

[Pulsebot]

default (115.22esr) revision https://hg.mozilla.org/releases/mozilla-esr115/rev/605716d71c48

Comment 25

[Yannis Juglaret [:yannis]]

Attachment: Example code highlighting the difference in behavior between duplicating -1 and -2

After actual testing that contradicted my initial intuition regarding whether this qualifies as a Microsoft bug (I now think yes), I filed the following with MSRC together with the attached source code:

Description of vulnerability:

Chromium has recently fixed CVE-2025-2783 by filtering the parameters passed to DuplicateHandle in Mojo IPC code. We at Mozilla have had to do the same and released a similar security fix.

We would like to highlight the fact that the root cause for this security issue lies within an undocumented behavior of DuplicateHandle, and that we believe that this would deserve a fix at the API level and not just at the application level, to ensure that all applications using this API are safe against this attack.

The behavior of DuplicateHandle is inconsistent when asked to duplicate the current process (-1) or current thread (-2) pseudo handle from a remote source process:
(a) when the source process is a remote process and we duplicate -1, the target handle will be a handle to the remote process;
(b) when the source process is a remote process and we duplicate -2, the target handle will be a handle to the current thread in the current process (the actual current thread).

(a) is a documented special case behavior, and isn't problematic here because the remote process already has a handle to its own process. However (b) is undocumented and problematic: when we call DuplicateHandle, we think we are always duplicating a handle to an object that the remote process already has access to, but in reality in this case we are creating a handle to an object (the current thread) to which the remote process doesn't have access currently. If we later duplicate it back to the remote process thinking that "this will be fine since the remote process already had a handle to this object", the remote process will now be able to use the new handle to manipulate the current thread and take control of it.

Because (b) is an undocumented behavior that has proven to be harmful, we believe that this behavior could and should be changed at the API level so that we only duplicate a handle to the current thread if the source process is the current process. More generally, except for -1 which would preserve its documented behavior, DuplicateHandle should fail to duplicate all other pseudo handles if the source process is a remote process, and in particular -2.

How to reproduce:

Run the attached program. It will output something like the following:

Parent running with process ID 28576, current thread ID 33212
Created child process with PID 7088
Target handle is a handle to process 7088
Target handle is a handle to thread 33212

We would expect the more reasonable behavior below:

Parent running with process ID 28576, current thread ID 33212
Created child process with PID 7088
Target handle is a handle to process 7088
Error during handle duplication for GetCurrentThread()

Comment 26

[Yannis Juglaret [:yannis]]

MSRC replied that they are planning a documentation update on the handleapi.h API page to clarify this behavior for developers. As far as I understand, the behavior will remain unchanged.

Comment 27

[Andrew McCreight [:mccr8]]

The Chromium issue is public now.