Environment:

• Firefox Quantum 68.0.1 (64 bit)
• Windows 10 Pro Version 1903 (64 bit)
• Skype Meetings App 16.2.0.511

Vulnerability Type:
Denial of Service

Description:
A webpage continuously redirecting to a URL handler can cause a denial of service against a user. If user has previously checked "Always Allow" when launching a URL handler, the site can repeatedly launch the associated program without user interaction. Depending on the process being launched, Windows can become unresponsive due to high resource usage.

If the URL protocol was set to "Always Ask", Firefox will will continually open windows asking the user to choose an application to open the link with, stealing window focus.

Steps to reproduce:
(Scenario 1 - Always Allow)

1. Install the Skype Meetings App [16.2.0.511]. (https://az801095.vo.msecnd.net/prod/LWA/plugins/windows/SkypeMeetingsApp.msi)
2. Join any Skype Business meeting. (https://meet.lync.com/microsoft/sebros/7QRH5WR8?sl=1)
3. When prompted, check "Remember my choice for sfb links" and open the link with "Skype Meetings App".
4. Close the Skype Meetings App.
5. Open URL Protocol Spam.html and click "Spam Skype Meetings App"

(Scenario 2 - Always Ask)

1. Install the Skype Meetings App [16.2.0.511]. (https://az801095.vo.msecnd.net/prod/LWA/plugins/windows/SkypeMeetingsApp.msi)
2. Open URL Protocol Spam.html and click "Spam Skype Meetings App".

Suggested fix:
Limit how frequently a site can redirect to a URL protocol.

Additional details:
This issue did not affect Google Chrome, Microsoft Edge, or Internet Explorer. Edge and IE hang until the loop is complete, then launch whatever URL protocol was called last. Chrome only launched URL protocols during the first loop.

Related issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1565574

Alternative "Always Ask" scenario that doesn't require installing any software.

1. Make a clean, default install of Firefox.
2. Open URL Protocol Spam.html and click "Spam Mailto".

We have other public DOS issues (basically anything that loops IPC) so it would probably be fine to unhide this. Leaving it hidden for the moment to get a second opinion.

Could have sworn that this was already on file but I can't find it, possibly because bugzilla search is terrible.

FWIW, I think the use of location.replace is... odd. It makes me suspect that the difference with other browsers is more about how we implemented location.replace (which we have other, non-security bugs on file for), and yet changing that would have no bearing on the security/DOS side here. That is, I wouldn't be surprised if you could achieve the same thing in other browsers by using .click() on links (perhaps _blank links), and/or using iframes.

Trying the attached testcase with mailto in Chrome, in the debugger I get a warning about throttling navigation that points to https://bugs.chromium.org/p/chromium/issues/detail?id=882238 ... which is restricted, so that's helpful...

I'm not 100% sure how best to fix this. It sounds like what we want is 1 free access to an external protocol (per toplevel document), and gating everything else on popup blocker state (so that the user clicking multiple mailto: links on 1 page would still work, but the webpage itself opening multiple things wouldn't). Of course, that's easier said than done.

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

FWIW, I think the use of location.replace is... odd. It makes me suspect that the difference with other browsers is more about how we implemented location.replace (which we have other, non-security bugs on file for), and yet changing that would have no bearing on the security/DOS side here.

This issue can also be reproduced with window.location.assign(url) or window.location.href = url.

(In reply to Steven M. Vascellaro from comment #4)

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

FWIW, I think the use of location.replace is... odd. It makes me suspect that the difference with other browsers is more about how we implemented location.replace (which we have other, non-security bugs on file for), and yet changing that would have no bearing on the security/DOS side here.

This issue can also be reproduced with window.location.assign(url) or window.location.href = url.

Sure, but that mostly devolves to the same thing. I'm curious about other ways of navigating that don't use window.location and/or that don't navigate the current browsing context.

I'm sure there's an "eviltraps" bug where someone opened 1000 iframes on mailto: links because mailto is one of the few whitelisted protocols that doesn't ask by default.