2025890 - Handling of ExternalHelperApp information should not trust URL / file information from the child process (either vet based on process or avoid IPC for this if possible)

Status: RESOLVED DUPLICATE of bug 2039452

(Firefox :: File Handling, task, P2)

Description

[Joren Afman]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:148.0) Gecko/20100101 Firefox/148.0

Steps to reproduce:

1. From a compromised content process, send PExternalHelperApp constructor with:
   • uri: file:///path/to/existing/executable
   • aWasFileChannel: true (spoofed)
   • aMimeContentType: a type with useHelperApp preferred action and alwaysAsk=false
2. The parent process trusts WasFileChannel() from ExternalHelperAppParent
   (uriloader/exthandler/ExternalHelperAppParent.cpp:48)
3. In nsExternalAppHandler action processing (nsExternalHelperAppService.cpp:1917):
   mIsFileChannel = true causes the code to take the LaunchLocalFile() path
4. LaunchLocalFile() (line 2694) extracts file path from the URI and calls
   mMimeInfo->LaunchWithFile(file)

Actual results:

The content-supplied boolean is trusted. If the MIME type conditions are met
(registered handler, alwaysAsk=false, non-saveToDisk action), LaunchLocalFile()
runs the file with the OS handler.

Mitigations: Windows executable checks force alwaysAsk=true for executables.
On Linux/macOS, weaker executable detection may allow more file types through.
The extensive alwaysAsk logic catches most cases, but the trust of
aWasFileChannel from content is a defense-in-depth failure.

AFFECTED CODE:

• uriloader/exthandler/ExternalHelperAppParent.cpp:48 (WasFileChannel from IPC)
• uriloader/exthandler/nsExternalHelperAppService.cpp:1632-1638 (trusts WasFileChannel)
• uriloader/exthandler/nsExternalHelperAppService.cpp:1917 (LaunchLocalFile branch)
• uriloader/exthandler/nsExternalHelperAppService.cpp:2694 (LaunchLocalFile)

Expected results:

The parent process should NOT trust aWasFileChannel from content. It should
independently verify whether the URI is a file:// URI. Additionally, file://
URIs in PExternalHelperApp from web content processes should be rejected since
web content should never trigger external helper apps for local files.

Comment 1

[:Gijs (he/him)]

Can you attach a concrete PoC that shows this actually working?

(In reply to Joren Afman from comment #0)

It should independently verify whether the URI is a file:// URI.

I don't see how this makes a difference, the URI is child-supplied.

The description of how LaunchWithFile works and the executable checks also seems mistaken / half-AI-slop (on non-Windows, LaunchWithFile will never directly launch the file, always trying to find a helper application to invoke to open it, and there are no executable checks in that part of the codepath).

A concrete PoC would help determine what is actually happening and how we might mitigate.

Comment 2

[Joren Afman]

You're right on both points — the URI is also child-supplied, and I was also wrong about the non-Windows LaunchWithFile behavior (it uses a helper application, not direct execution).

I don't have a concrete PoC for this as it requires sending crafted IPC messages from a compromised content process, which I cannot easily demonstrate.

The finding was based on static code analysis which identified that aWasFileChannel is trusted from the content process without independent verification, but I acknowledge the practical impact is less clear than the report suggested. If you don't consider this a meaningful security concern, I understand closing it.