1828334 - (CVE-2023-6871) Protocol handler warning should not be skipped for external scheme URLs entered directly in the addressbar (or other UI)

Status: RESOLVED FIXED

(Firefox :: Security, defect, P1)

Description

[Roy.Gunsen]

Attachment: Protocol Handler Warning Bypass.pdf

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:[e-mail]”.

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.

Comment 1

[Roy.Gunsen]

I realized the recording is too large for upload, should I upload a multi-part zip, or is another method more useful?

Comment 2

[Daniel Veditz [:dveditz]]

We don't need a video—in fact prefer not taking up the space—unless the description is hard to understand or we can't reproduce the problem. Your PDF with screenshots is nicely done.

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.

Social engineering is about the furthest thing from a "zero-click" attack. "zero-click" meaning the user doesn't have to do anything to get compromised, not even clicking on an evil link. Examples include some of the iPhone vulnerabilities where someone could send a malicious iMessage and compromise your phone just by receiving it, without you even unlocking the phone to read it. Or the Samsung "Voice over LTE" issue in Exynos chips. Social engineering is high engagement.

~ 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.

These three attacks are orders of magnitude more serious than changing someone's home page. Yes, you could do that, but if you've pulled off one of these attacks why would you bother rather than directly do whatever this homepage attack might accomplish for you?

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

This seems to be a philosophical difference between Firefox and Chrome. Our warning is not to prevent the user from opening a protocol handler they've asked for, it's to warn them that a web page is trying to do something unusual and potentially dangerous. That does mean there's more risk of social engineering for Firefox users, but in practice we've seen these kind of social engineering (with other similar kinds of warnings) just tell people to expect the warning and click "OK" so I'm not sure it's a difference in practice.

Your point about Firefox allowing these as a home page is a good one. I'm not convinced it's an "attack" given the capabilities the attacker would have to have to get there, but there's no good reason for it and we could restrict the homepage to a "web-safe" set (and include about: and moz-extension).

Comment 3

[Daniel Veditz [:dveditz]]

A more generic version of the homepage problem was stated as bug 1780484 (validate the URLs) but without noting the problems that could be caused by external protocol handlers causing a hang.

I don't think we have any desire to change the lack of a warning when a user explicitly enters the external scheme into the address bar and don't consider it a security problem (Gijs: what do you think?)

It would be good to restrict and validate the homepage URLs, but I'm not convinced the lack of doing so is a security problem in itself. Web extensions can only register their own pages as home pages, users can make terrible setting choices that break their browser in many ways, and locally-running programs messing with preferences is outside a realistic threat model on a personal computer.

Comment 4

[Roy.Gunsen]

Hi Daniel,

Thanks for your thorough response.

That is a fair point, I intended to say that it could lead to a zero-click in the cloud-sync, lateral movement, and local persistence methods, not via copy-pasting a malicious URL.
As you mention, it wouldn't be a "zero-click" as the user would need to open Firefox, but I do think it is worth considering the cloud-sync avenue for setting the homepage, as the only user interaction required is to already have cloud-sync enabled, and to open reopen Firefox.

The persistence and lateral movement points are another consideration as to why a warning might be helpful, but I agree the only realistic attack scenario via cloud-sync settings.

Regarding the following point:

• "These three attacks are orders of magnitude more serious than changing someone's home page. Yes, you could do that, but if you've pulled off one of these attacks why would you bother rather than directly do whatever this homepage attack might accomplish for you?"

From my research the only other way to get remote-code execution from a cloud-sync browser session without any user interaction outside of opening the cloud-synced browser is via a malicious extension, which to the best of my knowledge has its own security vetting to avoid misuse. I have done some research into this if you would like me to provide further insight, but I presumed that malicious extensions were considered a separate issue due to the vetting process.

As far as additional context on homepage URL safety, Edge and Chrome both have an explicit blocklist of URLs you can not set the homepage to, such as "chrome://kill". I haven't looked too deeply into the Firefox equivalent, but this may also be worth considering.

Let me know if you have any further questions or comments.

Comment 5

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #3)

I don't think we have any desire to change the lack of a warning when a user explicitly enters the external scheme into the address bar and don't consider it a security problem (Gijs: what do you think?)

I concur it's not a serious security problem.

However, I think this is a relatively recent change. I think previously there was a prompt to confirm the app to use for the protocol. This changed with bug 1731898. This switched us from 2 to 1 prompt for websites, but it also switched from 1 to 0 prompts for the address bar.

I don't think it's a big deal to switch that back for the address bar / system principal if we so desire, so the user gets prompted the first time a given protocol is invoked. Dan, wdyt?

locally-running programs messing with preferences is outside a realistic threat model on a personal computer.

(In reply to Roy.Gunsen from comment #4)

As you mention, it wouldn't be a "zero-click" as the user would need to open Firefox, but I do think it is worth considering the cloud-sync avenue for setting the homepage, as the only user interaction required is to already have cloud-sync enabled, and to open reopen Firefox.

I'm confused, wouldn't the user also need to have a local program installed that listens for this protocol?

If the attacker is able to install this program locally on the user's machine, they can clearly run arbitrary code on that machine anyway. So what does adding the indirection via Firefox and the protocol handler add?

(Obviously this doesn't help for protocols that ship with the OS, but if the OS ships protocol handlers that do dodgy stuff by default then that's an issue to take up with the OS vendors, IMO - as Dan said, it's pretty easy to convince browser users to click "yeah sure" in dialogs. On the browser side we can block them entirely on a case-by-case basis where appropriate, though it's a little whack-a-mole.)

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.

I can't reproduce this and would appreciate more specific steps about what you mean by this, because it sounds like a separate issue.

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.

We can block these protocol handlers altogether in a separate bug, which seems reasonable anyway, based on this description, separate from any filtering we might want to do for the homepage.

Comment 6

[Roy.Gunsen]

• I'm confused, wouldn't the user also need to have a local program installed that listens for this protocol?

I think my major concern is in apps that ship with windows, or are commonly installed such as Zoom, Java, Teams, etc. Teams has had RCE in it in the past, as has default windows protocol handlers such as ms-search. Java currently has RCE in it after an additional prompt is raised.

• I can't reproduce this and would appreciate more specific steps about what you mean by this, because it sounds like a separate issue.

The first time I submit a protocol handler URL to Firefox, rather than trigger the protocol handler, it does nothing. Leaving me on a blank page with the URL still containing the link to the protocol handler. Here are three protocol handlers this functionality worked for me on:

• calculator:calc
• ms-holographicfirstrun:aaa
• ms-get-started:aaa

I've attached two screenshots, but its a bit hard to show. I can send through a screen recording if needed.

Comment 7

[Roy.Gunsen]

Attachment: Holo2.PNG

Comment 8

[Roy.Gunsen]

Attachment: Holo1.PNG

Comment 9

[Roy.Gunsen]

Hi Gijs,

I saw you submitted the Dos from within this as CVE-2023-32214.
Can I be added as a reporter for it? Under the name "Edward Prior" ideally.

I would have posted it in the other thread, but I don't appear to be able to post in a closed thread.

Comment 10

[:Gijs (he/him)]

(In reply to Roy.Gunsen from comment #9)

Hi Gijs,

I saw you submitted the Dos from within this as CVE-2023-32214.

I don't deal with CVEs so this wasn't me. Passing the below request to Tom instead.

Can I be added as a reporter for it? Under the name "Edward Prior" ideally.

Comment 11

[Andrew McCreight [:mccr8]]

(In reply to Roy.Gunsen from comment #9)

I would have posted it in the other thread, but I don't appear to be able to post in a closed thread.

For future reference, for things like CVE issues, you are probably better off emailing [e-mail].

Comment 12

[Tom Ritter [:tjr]]

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

(In reply to Roy.Gunsen from comment #9)

I would have posted it in the other thread, but I don't appear to be able to post in a closed thread.

For future reference, for things like CVE issues, you are probably better off emailing [e-mail].

Yes. To close my needinfo - I corrected the oversight in https://github.com/mozilla/foundation-security-advisories/commit/a6d5e678789ab730e3e9c0f77a05f0d4aa08f32f - thanks and sorry.

Comment 14

[Daniel Veditz [:dveditz]]

(In reply to :Gijs (he/him) from comment #5)

previously there was a prompt to confirm the app to use for the protocol. This changed with bug 1731898. This switched us from 2 to 1 prompt for websites, but it also switched from 1 to 0 prompts for the address bar.

I don't think it's a big deal to switch that back for the address bar / system principal if we so desire, so the user gets prompted the first time a given protocol is invoked. Dan, wdyt?

I think we do have to put this friction back into the browser. It doesn't "solve" the problem because some number of users are going to open it anyway, but the unexpected prompt might give a lot of them time to have a second thought about it.

Are you proposing just to bring back the old dialog with the same options? That works for me. If not we might have to argue about what you mean by "first time". If the attacker just has to run the attack twice to get through then that's not much protection. I agree users should have the option to remember the choice, but users need to have the option to NOT remember that's easier than having to go into preferences and manually change the option every time they encounter a new protocol.

This doesn't solve Roy's concern about someone hacking a cloud-sync profile. If you can hack it to change someone's home page then you could also change their preferences to "remember" to use that protocol without asking. That seems outside the scope of what we can reasonably expect to protect against. Our own Sync product encrypts the shared data on the client so that it can't possibly be modified or read even if our sync servers do get hacked. Does Chrome or Edge have a solution for this problem?

(Obviously this doesn't help for protocols that ship with the OS, but if the OS ships protocol handlers that do dodgy stuff by default then that's an issue to take up with the OS vendors, IMO - as Dan said, it's pretty easy to convince browser users to click "yeah sure" in dialogs. On the browser side we can block them entirely on a case-by-case basis where appropriate, though it's a little whack-a-mole.)

Way too many programs that the user never chose to put on their machine advertise themselves as URL handlers, and many of them are in "barely maintenance mode" but can't be removed because Microsoft supports old customer use-cases practically forever. Remember those .diagcab files that caused us trouble? The Microsoft Support Diagnostic Tool is officially deprecated but won't actually be removed from anyone's machines until 2025 (not clear if that even applies to Windows 10 or only Windows 11).

We should do what we can to make it hard to get to these uncommon handlers unintentionally. As the recent Google Security post on the state of 0-days in 2022 notes,

Advances in the defenses of the top browsers is likely influencing the push to other components as the initial vector in an exploit chain.
...
In 2022, more attackers began moving to using 0-click exploits instead, exploits that require no user interaction to trigger. 0-clicks tend to target device components other than browsers.

This doesn't fit their definition of "0-click" in any way, but it does illustrate attackers are looking for vectors that get around the browser, and that they are sensitive to the number of interactions required to launch.

Comment 15

[Roy.Gunsen]

I think the simplest solution to reduce the likelihood of a user getting compromised via this is to bring the prompt back.

I do agree that the circumstance where this could be considered a 0-Click is very contrived. I think the more likely circumstance is attackers would leverage cloud-sync to send users to phishing sites. But that's basically impossible to prevent with the current setup.

My thoughts for other changes are:

• Limit the starting page to a regex match of ^https?:// , or potentially a regex that allows local file locations as well. Note, Chrome and Edge have a blocklist for this. Eg, you cant set your homepage to edge://restart/ in Edge because it would force a boot loop. I don't believe I saw one on Firefox.
• Consider swapping to an allowlist of trusted application handlers.

I noticed Firefox doesn't synchronise a lot of sensitive settings such as remembering protocol usage, and the location downloaded files are saved to disk. It could be worth going through the list of synced settings and checking for anything problematic.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1731898

:sclements, since you are the author of the regressor, bug 1731898, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 17

[Daniel Veditz [:dveditz]]

(Note: the linked Google Blog post currently doesn't load in Firefox for a lot of people -- a jQuery regexp in the page is timing out and throwing a "too much recursion" exception. We're aware and people are looking into it)

Comment 18

[Sarah Clements [:sclements]]

To clarify, is the proposed solution to bring back the prompt just for the address bar? I need these requirements nailed down before I can work on a fix. I also need an opinion on severity since this is clearly a security issue but this bug was also filed 4 months ago.

Comment 19

[:Gijs (he/him)]

(In reply to Sarah Clements [:sclements] from comment #18)

To clarify, is the proposed solution to bring back the prompt just for the address bar?

Just for system principal. Which is the address bar, some of the drag & drop cases, etc. But not "normal" link clicks in websites.

I need these requirements nailed down before I can work on a fix. I also need an opinion on severity since this is clearly a security issue but this bug was also filed 4 months ago.

It's marked sec-low, so it's not high/critical severity, but it's also (I think) a relatively small patch. Specifically, I think this condition could be updated to add !aPrincipal?.isSystemPrincipal, so that in that case we don't skip the dialog.

(In reply to Roy.Gunsen from comment #15)

• Limit the starting page to a regex match of ^https?:// , or potentially a regex that allows local file locations as well. Note, Chrome and Edge have a blocklist for this. Eg, you cant set your homepage to edge://restart/ in Edge because it would force a boot loop. I don't believe I saw one on Firefox.

It would be useful to file a separate bug for this. I agree it would be a reasonable improvement.

• Consider swapping to an allowlist of trusted application handlers.

Unfortunately, I don't think this is feasible. Every app and their competitor has one of these protocols, and only allowlisting the common ones would effectively help create an oligopoly for the existing players in a given market (e.g. MS teams, zoom, cisco, meet.google.com, for video conferencing; apple music, spotify and windows' music stuff for music; etc.). We try to avoid doing this (ie preferring large companies that are already in a space in terms of how the browser treats them) in general. There is currently an allowlist for protocols that websites are allowed to register, but there is active work to change that, arguing that browsers should not be responsible for maintaining that list, and that is therefore likely to switch to a block- rather than allowlist in future.

I noticed Firefox doesn't synchronise a lot of sensitive settings such as remembering protocol usage, and the location downloaded files are saved to disk. It could be worth going through the list of synced settings and checking for anything problematic.

The download destination probably isn't synced because syncing paths across devices is a recipe for failure (they might not exist, or even be legal paths, on the other device which may run a different OS or have different file system restrictions). Protocol usage isn't synced, for one because it's not in the prefs storage but elsewhere (handlers.json) and for another because it suffers from the same issue (you can configure custom handling executables and those have paths so we're back to the same problem).

In general the sync/fxa team should be bearing some of this stuff in mind when deciding what prefs get synced, and we have made changes there over time for security reasons as well. I'm not sure that a new audit would find anything new - though of course, if you think there are things that are synced that shouldn't be, filing separate bugs would be useful.

Comment 20

[Sarah Clements [:sclements]]

(In reply to :Gijs (he/him) from comment #19)

(In reply to Sarah Clements [:sclements] from comment #18)

To clarify, is the proposed solution to bring back the prompt just for the address bar?

Just for system principal. Which is the address bar, some of the drag & drop cases, etc. But not "normal" link clicks in websites.

I need these requirements nailed down before I can work on a fix. I also need an opinion on severity since this is clearly a security issue but this bug was also filed 4 months ago.

It's marked sec-low, so it's not high/critical severity, but it's also (I think) a relatively small patch. Specifically, I think this condition could be updated to add !aPrincipal?.isSystemPrincipal, so that in that case we don't skip the dialog.

Thanks for clarifying.

Comment 21

[Sarah Clements [:sclements]]

Attachment: Screenshot 2023-08-07 at 2.57.19 pm.png

So after digging into this, it seems that the issue is specifically protocol handlers where there is a system protocol, so ms-specific protocols per the STR and itunes: on mac. With protocol handlers where there's a default app, that's also where I see that typing it into the url bar and hitting enter doesn't always open the app right away, you do have to hit enter twice sometimes.

For protocols where you need to download the app, say zoom, I can easily verify that if I open firefox with a new profile, copy/paste a zoom meeting url into the address bar and hit enter, I do in fact see this protocol prompt show up (on both mac and windows). And if for example, I don't have zoom installed yet, the protocol handler doesn't open, instead you see a web page from zoom prompting the user to download the app and/or click the web link instead.

So to confirm this is the change we want: if a user uses a protocol where there is a system app, we don't skip the permission dialog, we show it unless that user hits the "Always allow" checkbox (same as what we do for other protocols). On Edge, if I type "ms-photos:photos" in the url bar it shows the prompt that the website is trying to open Photos with an "open" or "cancel" option, so there's never an option to "always allow" and bypass it.

Comment 22

[Sarah Clements [:sclements]]

Attachment: Screenshot 2023-08-07 at 6.33.38 pm.png

We can get back to this screen for system-specific protocols but either way I think that means we modify_hasProtocolHandlerPermission used here that was added in bug 1565574.

Comment 23

[Sarah Clements [:sclements]]

Aha! What we need is to add !aPrincipal.isSystemPrincipal to here. That should bring the dialog back.

Comment 24

[Sarah Clements [:sclements]]

Attachment: Bug 1828334 r=Gijs,dveditz

• Add condition for aPrincipal.isSystemPrincipal in _hasProtocolHandlerPermission

Comment 25

[:Gijs (he/him)]

(In reply to Sarah Clements [:sclements] from comment #21)

For protocols where you need to download the app, say zoom, I can easily verify that if I open firefox with a new profile, copy/paste a zoom meeting url into the address bar and hit enter,

I think here you're using https://blah.zoom.us/<morethings> as the "meeting url".

But "behind the scenes" that opens zoommtg:... URLs. If you discover that precise URL (you can find it in the debugger when the dialog is shown, for instance, but IIRC once you know the format and know the room #, it's pretty straightforward to predict), and paste that zoommtg:... string in the URL bar and hit enter, that will behave the same as the itunes: and ms-blah URLs.

Comment 26

[:Gijs (he/him)]

Sarah, is there something I can do to help you move forward here?

Comment 27

[Sarah Clements [:sclements]]

(In reply to :Gijs (he/him) from comment #26)

Sarah, is there something I can do to help you move forward here?

Sorry for the delay, I've been swamped with release work. I should be able to get back to this next week.

Comment 28

[Sarah Clements [:sclements]]

(In reply to :Gijs (he/him) from comment #25)

(In reply to Sarah Clements [:sclements] from comment #21)

For protocols where you need to download the app, say zoom, I can easily verify that if I open firefox with a new profile, copy/paste a zoom meeting url into the address bar and hit enter,

I think here you're using https://blah.zoom.us/<morethings> as the "meeting url".

But "behind the scenes" that opens zoommtg:... URLs. If you discover that precise URL (you can find it in the debugger when the dialog is shown, for instance, but IIRC once you know the format and know the room #, it's pretty straightforward to predict), and paste that zoommtg:... string in the URL bar and hit enter, that will behave the same as the itunes: and ms-blah URLs.

Ah, right - zoommtg does indeed behave the same way.

Comment 29

[Daniel Veditz [:dveditz]]

(In reply to :Gijs (he/him) from comment #19)

(In reply to Roy.Gunsen from comment #15)

• Limit the starting page to a regex match of ^https?:// , or potentially a regex that allows local file locations as well. Note, Chrome and Edge have a blocklist for this. Eg, you cant set your homepage to edge://restart/ in Edge because it would force a boot loop. I don't believe I saw one on Firefox.

It would be useful to file a separate bug for this. I agree it would be a reasonable improvement.

bug 1780484 is intended to cover that. If it's not clear enough please add comments

Comment 30

[:Gijs (he/him)]

Attachment: WIP: Bug 1828334 - Test fix

Comment 31

[Roy.Gunsen]

Hi All,

I have been approved to talk at Blackhat regarding how Cloud-Synchronization affects browser security, I am hoping to discuss this vulnerability (amongst others), as a part of that talk.

Would it be possible to get this patched prior to the 6th of December? Or could I get the okay to discuss it if it is still unpatched?

Sorry for the late notice, I only found out recently and have been busy getting other things sorted for it.

Regards,
Ed.

Comment 32

[Andrew McCreight [:mccr8]]

It looks like 120 will be released on November 21, so that will be the version we'd have to fix this in to have it done by December 6th.

Comment 33

[Sarah Clements [:sclements]]

I'll continue work on this tomorrow, but no promises - there is test bustage to work through.

Comment 34

[Frederik Braun [:freddy]]

(In reply to Roy.Gunsen from comment #31)

I have been approved to talk at Blackhat regarding how Cloud-Synchronization affects browser security, I am hoping to discuss this vulnerability (amongst others), as a part of that talk.

Congratulations!

Would it be possible to get this patched prior to the 6th of December? Or could I get the okay to discuss it if it is still unpatched?

We'd prefer if you could keep the details hidden until we have had the chance to protect our users. Our full stance on disclosure is in the bug bounty FAQ at https://www.mozilla.org/en-US/security/bug-bounty/faq/#nondisclosure

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d7ba64895091
r=Gijs,dveditz,extension-reviewers,fluent-reviewers,flod,robwu

Comment 36

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/36f2efb02d43
Backed out changeset d7ba64895091 for causing talos damp hangs.

Comment 37

[Dianna Smith [:diannaS]]

Backed out for causing talos hangs

• Backout link
• the Runs hang for 1hr after this line in the log

Comment 38

[Sarah Clements [:sclements]]

I can see why that damp test failed locally, when I run ./mach talos-test --suite damp --subtests webconsole --cycles 1 --tppagecycles 1. We now see a permission dialog asking to "Open the ext+damp link with damp protocol", and that's causing the test to hang and time out. I've traced that to this manifest but since I'm neither familiar with devtools/addons code nor damp/talos performance tests so this is very confusing to debug.

Since this test seems to be about performance of the page load, my initial thought is in order to by-pass the dialog we could add some sort of value/arg to that manifest of triggeredExternally: true so as to bypass the dialog. But I can't quite figure out where the handleURI of ContentDispatchChooser is called and whether that manifest file is the right place to do so. It seems like it might be part of set up, before even the damp.html is loaded based on what I'm seeing in the terminal:

started process 14848 (/Users/sarah/mozilla-unified/objdir-frontend/dist/Nightly.app/Contents/MacOS/firefox -foreground --no-remote -profile /var/folders/n4/xbx64n7n093f0f1j2749s34w0000gn/T/tmprb2n5yv3/profile)
16:35:36     INFO -  PID 14848 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
16:35:36     INFO -  PID 14848 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
16:35:37     INFO -  PID 14848 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
16:35:37     INFO -  PID 14848 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
16:35:37     INFO -  PID 14848 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
16:35:37     INFO -  PID 14848 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
16:35:37     INFO -  PID 14848 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
16:35:37     INFO -  PID 14848 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
16:35:37     INFO -  PID 14848 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
16:35:37     INFO -  PID 14848 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
16:35:37     INFO -  PID 14848 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
16:35:37     INFO -  PID 14848 | console.error: (new InvalidStateError("JSWindowActorParent.sendAsyncMessage: JSWindowActorParent cannot send at the moment", (void 0), 536))
16:35:37     INFO -  PID 14848 | console.error: (new InvalidStateError("JSWindowActorParent.sendAsyncMessage: JSWindowActorParent cannot send at the moment", (void 0), 536))

^It hangs here until you click the "open link" button in the dialog, so then it looks like damp.html is loaded and thus the scripts from driver.js and api.js.

16:35:40     INFO -  PID 14848 | [damp-api] Retrieve the main DevTools loader
16:35:40     INFO -  PID 14848 | [damp-api] Retrieve the DAMP runner and start the test
16:35:40     INFO -  PID 14848 | [DampLoad helper] Register DampLoad actors
16:35:41     INFO -  PID 14848 | Garbage collect
16:35:42     INFO -  PID 14848 | Loading test 'webconsole/cold-open.js'
16:35:42     INFO -  PID 14848 | Executing test 'webconsole/cold-open.js'

:robwu and :Gijs, please let me know if you have some suggestions or insight into this test.

Comment 39

[Paul Zühlcke [:pbz]]

I'm not familiar with that specific test, but would setting the open-protocol-handler permission for the test site work?

Comment 40

[Rob Wu [:robwu]]

The issue is not specific to damp tests. There are two instances that register a custom protocol that are going to be handled by the extension. That is, these two protocols redirect to a moz-extension:-URL:

• ext+damp at https://searchfox.org/mozilla-central/rev/8acfbe4ba09b46b91c862dc2fbc064d4fc1bac9a/testing/talos/talos/tests/devtools/addon/manifest.json#14
• ext+twinopen at https://searchfox.org/mozilla-central/rev/8acfbe4ba09b46b91c862dc2fbc064d4fc1bac9a/testing/talos/talos/tests/twinopen/manifest.json#14

Judging by the failure and the change in the patch, it looks like these schemes are opened from a system principal, and the open-protocol-handler^ext+damp and open-protocol-handler^ext+twinopen permissions aren't working because that check is skipped by the patch, by https://hg.mozilla.org/integration/autoland/rev/d7ba64895091#l3.52

If we return to the drawing board - the purpose of the patch to this bug is to prevent external protocol handlers from being triggered without user interaction. I think that it is safe to keep the current behavior for protocols that are handled within the browser ("safe schemes" from registerProtocolHandler and certain schemes with the ext+ and web+ prefix - see extension_protocol_handlers.json) . Or at the very least, we can prioritize the fix for external protocol handlers and defer the behavioral change for these internal schemes to a follow-up.

There is no guarantee that the URL is going to be opened in Firefox, even if the protocol handler is in the format described above. One of the ways to determine whether a protocol is going to open internally, is to look up the protocol handler and see if it maps to a URL that starts with http(s): or moz-extension:. The extension-registered protocol handlers are implemented in ext-protocolHandlers.js. To detect them, you'd have to add a check that mirrors that logic. It looks like that logic exists at https://searchfox.org/mozilla-central/rev/8acfbe4ba09b46b91c862dc2fbc064d4fc1bac9a/toolkit/mozapps/handling/ContentDispatchChooser.sys.mjs#58-62 , but only to skip a prompt loop. I suppose that you could add a similar check to weaken the condition that you've added in the patch. When you do, ask Gijs for another review.

Comment 41

[:Gijs (he/him)]

I don't love specialcasing web+/ext+ schemes.

An alternative could be setting security.external_protocol_requires_permission to false for these performance tests.

Does that work? If so, it seems simpler and avoids changing code-under-test just for the performance test weirdness. Though ideally at some point we get rid of the pref so we'll need to reconsider this then, it seems more expedient than deferring fixing ext/web. Yes, ext/web protocols were not the original point of this bug (rather, issues/vulnerabilities in protocols implemented by other apps on the machine were), a priori there is no particular reason the same type of vulnerability couldn't exist with web- or extension-implemented protocols (albeit limited by virtue of the in-browser execution context vs. the unsandboxed OS-level app execution).

Comment 42

[Sarah Clements [:sclements]]

(In reply to :Gijs (he/him) from comment #41)

I don't love specialcasing web+/ext+ schemes.

An alternative could be setting security.external_protocol_requires_permission to false for these performance tests.

Does that work?

Yes, adding that pref to testing/profiles/perf/user.js gets the twinopen and damp tests passing locally.

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/89a118c58786
r=Gijs,dveditz,extension-reviewers,fluent-reviewers,flod,robwu,perftest-reviewers

Comment 44

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/89a118c58786

Comment 45

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:sclements, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox120 to wontfix.

For more information, please visit BugBot documentation.

Comment 46

[Sarah Clements [:sclements]]

I chatted with Gijs and because of the types of changes in this patch, it'd probably be best to let this ride the train for 121 rather than trying to uplift to beta.

Comment 47

[Jason Kratzer [:jkratzer]]

Attachment: advisory.txt

Comment 48

[Daniel Veditz [:dveditz]]

Bulk-unhiding security bugs fixed in Firefox 119-121 (Fall 2023). Use "moo-doctrine-subsidy" to filter