Bug: Protocol handler warning should not be skipped for external scheme URLs entered directly in the addressbar (or other UI)
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-04-16 14:58:29+00:00
Resolved: 2024-05-30 18:08:27+00:00

A full copy of this bug bounty submission with full screenshots can be found in the attached PDF file. I have also attached a video recording of the persistent soft lock. However, as this can't be recorded on the soft-locked device, the recording quality is quite low.

Issue Context

A protocol handler is an application that knows how to interpret particular types of links: for example, a mail client is a protocol handler for "mailto:" links. This allows external applications to be opened via a browser by navigating to a link such as “mailto:client@domainname.internal”.

Upon navigating to a protocol handler URL such as “calculator:calc” or “microsoft.windows.camera:aaaa”, browsers warn the user prior to triggering the protocol handler. This is due to how protocol handlers allow for the execution of programs outside of the browser context, and the security of these protocol handlers is outside of the browsers control.

Firefox will raise a warning prior to triggering the protocol handler in the following circumstances:
~ Navigation to a URL via an “<a>” tag.
~ A JavaScript redirect, such as window.open("calculator:calc").
~ Header based-redirects.



Issue description

Despite using a warning if a protocol handler URL is navigated to via the previously specified method, Firefox skips this check if the URL is directly navigated to directly via the URL bar. This can be done by entering it into the URL bar and pressing the “enter” key, or by setting the browser homepage to a URL containing a protocol handler and then re-opening Firefox.

One caveat to the above description is that the first time Firefox encounters a new protocol handler, it appears to silently ignore the request, and then upon any subsequent request it will automatically open.

This effectively circumvents the protection to prevent users from inadvertently executing protocol handlers.



Impact

Windows protocol handlers have been vulnerable to a number of remote code execution vulnerabilities in the past, any of which could have been leveraged in combination with this to function as a zero-click remote code execution vulnerability. Three such vulnerabilities are shown below:
~ https://positive.security/blog/ms-officecmd-rce
~ https://blog.doyensec.com/2018/05/24/electron-win-protocol-handler-bug-bypass.html
~ https://www.bleepingcomputer.com/news/security/new-windows-search-zero-day-added-to-microsoft-protocol-nightmare/

Zero-click Remote Code Execution

Real world situations where this is able to be leveraged as a zero-click remote code execution would include: 
~ Social engineering, where a user is coerced into copy-pasting a URL into Firefox.
~ Compromising a cloud-sync session and setting the user's homepage to a protocol handler URL.
~ Lateral movement within a network, where a user can modify a user’s homepage via modifying config files on a victim's machine via an SMB share functionality.
~ User or system level persistence on a device via modifying either the Firefox configuration files or the windows registry keys to allow setting the user’s homepage.

If an attacker has file access to the victim machine machine, such as the previous two examples, this can be done without the need for a protocol handler vulnerability, as the user can simply add an unsafe protocol handler with user level privileges.

One-click Remote Code Execution

Alternatively for a one-click remote code execution, an attacker could use the Java Network Launch Protocol if Java is installed upon the host. Further information on this can be found in the following whitepaper:
https://cybir.com/wp-content/uploads/2021/06/JNLP-Injection-and-Attacks-Release.pdf

A example of this attack is the the following URL 
“jnlp:https://docs.oracle.com/javase/tutorialJWS/samples/deployment/dynamictree_webstartJWSProject/dynamictree_webstart.jnlp”:

Upon clicking the run button, the Jar file referenced in the URL above is executed, in this case, opening a sample application.

Persistent Denial of Service

Another notable use for this vulnerability would be via the use of the “ms-cxh” and “ms-cxh-full” protocol handlers which can softlock some windows versions by creating a persistent black screen. This can be fixed through a series of commands found in the paper below, but is usually fixed with a full system reboot.
https://papers.vx-underground.org/papers/Windows/Analysis%20and%20Internals/2022-01-16%20-%20Notes%20on%20Windows%20MS-CXH%20and%20MS-CXH-FULL%20handlers.pdf


This was confirmed on an up-to-date windows version found here:
Edition: Windows 10 Home
Version: 21H2
OS Build: 19044.2846
Experience: Windows Feature Experience Pack 120.2212.4190.0

Once this setting is saved and Firefox is closed, every subsequent reopening of Firefox will soft-lock the computer. This will prevent all use of Firefox on the device without changing the specific file system configuration, as Firefox cannot be opened to remove this homepage setting. As this is a saved configuration, this will persist between reboots. To remove this soft-lock, the prefs.js file must be modified to remove the browser.startup.homepage value.



Steps to Replicate

Submit a protocol handler into the URL bar and press the “enter” key. If no applications open, re-submit the value and press the “enter” key again.

Here are three sample protocol handlers that will open an application on a default windows machine:
~ ms-photos:photos
~ microsoft.windows.camera:camera
~ ldap:ldap

To observe the homepage functionality, set the homepage at about:preferences#home to one of the above settings, then close and reopen Firefox. Once again, if no application opens on first reboot, close and reopen Firefox.



Remediation

Implement a protocol handler warning on all instances where a protocol handler is triggered from Firefox.