Closed Bug 1518627 (CVE-2019-11701) Opened 5 years ago Closed 5 years ago

Remove the default protocol handler for webcal given it has serious XSS vulnerabilities

Categories

(Firefox :: File Handling, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 67
Tracking Status
firefox-esr60 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- verified

People

(Reporter: p4fg, Assigned: Gijs)

References

()

Details

(Keywords: sec-low, sec-vector, wsec-xss, Whiteboard: [reporter-external] [client-bounty-form] [verif?][post-critsmash-triage][adv-main67+])

Attachments

(1 file)

Operating system: Ubuntu Linux 18.04 LTS
Firefox version: Firefox Quantum 64.0 (Mozilla Firefox for Ubuntu canonical-1.0)

I was looking around in about:config researching a totally different bug and found the following handler installed (by default i presume as i have not installed it):

gecko.handlerService.schemes.webcal.0.name;30 Boxes
gecko.handlerService.schemes.webcal.0.uriTemplate;https://30boxes.com/external/widget?refer=ff&url=%s

This service is unfortunately vulnerable, and as your general eligibility states that third-party websites utilized are in-scope ("We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.") i thought i would try to report this bug to get this handler removed.

To reproduce: either create the following url as a link or just paste it into the web-browser:

webcal://www.mozilla.org?q=<script>document.location='http://redirected.shellcode.se';</script>
(I created a simple link to this on a page on my domain: http://poc.shellcode.se/webcal.html)

Firefox asks if you want to open the link with the application "30 Boxes" (Unless the user has clicked "Remember my choice for webcal links"). Clicking ok will transfer the user to the url:

https://30boxes.com/external/widget?refer=ff&url=www.mozilla.org?q=webcal%3A%2F%2Fwww.mozilla.org%3Fq%3D%3Cscript%3Edocument.location%3D'http%3A%2F%2Fredirected.shellcode.se'%3B%3C%2Fscript%3E

This page is vulnerable to XSS and the javascript is executed. In this case only a "harmless" redirect.

I understand that the main bug is not on your domain, but the handler seems to be installed by default and thus affects the standard product.

Thanks for your time!
Best regards
Peter - Sweden

Flags: sec-bounty?

It seems that bugzilla is filtering out the script-tags in my report which probably makes it difficult to understand.

Please view the PoC on my page: http://poc.shellcode.se/webcal.html

Trying markdown:

webcal://www.mozilla.org?q=<script>document.location='http://redirected.shellcode.se';</script>
Attached video Video PoC of bug

Simple recording of the bug in action

dolske: who owns our default handlers? We should remove "30 Boxes" in any case but someone should go through the others and clean out the cruft.

Status: UNCONFIRMED → NEW
Component: Security → General
Ever confirmed: true
Flags: needinfo?(dolske)
Keywords: sec-vector, wsec-xss
Component: General → File Handling

Gijs, can you help here? Let's at least focus on nuking 30boxes in this bug, if we can easily clean out any other cruft while we're here great, otherwise let's spin that off to a new bug if it's complicated.

Flags: needinfo?(dolske) → needinfo?(gijskruitbosch+bugs)

Sure, I can attempt to come up with a patch tomorrow or later this week.

This is slightly messy because while just removing the existing handler option from the default prefs is easy, I'm not aware of a trivial way of migrating existing profiles; AIUI we import things from the prefs into the handlers DB. Paolo, can you point to any relevant precedent on how to update these and/or remove items?

:dolske: Should we point people to a SUMO page or something if we detect they were actually using this?

Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Flags: needinfo?(paolo.mozmail)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(dolske)

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

Paolo, can you point to any relevant precedent on how to update these and/or remove items?

See bug 1252831 comment 9, as well as bug 1252831 comment 12 and the following discussion. I'll be happy to review a patch in that bug, where you can also more easily notify the localization team and add a migration step to remove the old URLs. When looking for old URLs, note that there might be leftovers with slightly different alternate version of the URL found in localized repositories, or older versions with the HTTP scheme.

In bug 1252831 I originally said that the migration step shouldn't remove the handler if it already set as the default, but I'll leave this up to you and Dolske given this new bug. Pointing to a SUMO article might be worth doing if we change the current handler and remove the option to bring it back.

An alternative could be to leave the HTTPS version as an available handler, but not the default, if any other URL variation used to be the default on the system. After a release or two, we can run a similar migration step again, which should remove the option entirely if the user took no action and the handler is still not the default.

Flags: needinfo?(paolo.mozmail)
Priority: -- → P1

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

dolske: who owns our default handlers? We should remove "30 Boxes" in any case but someone should go through the others and clean out the cruft.

Ni me to look at the other stuff we still have...

Flags: needinfo?(dolske) → needinfo?(gijskruitbosch+bugs)

(In reply to Peter af Geijerstam from comment #0)

https://30boxes.com/external/widget?refer=ff&url=www.mozilla.org?q=<script>document.location='http://redirected.shellcode.se';</script>

This page is vulnerable to XSS and the javascript is executed. In this case only a "harmless" redirect.

I understand that the main bug is not on your domain, but the handler seems to be installed by default and thus affects the standard product.

Thanks again for reporting this. A fix has just been pushed to our alpha / nightly channel (should be available in the next 12-24h), and it should remove the handler completely.

I've tried in vain to find a contact point for 30boxes. Have you reported this issue to them at all?

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(p4fg)
Flags: needinfo?(gijskruitbosch+bugs)

I tried to message the owners of 30boxes, but cannot see that i ever got any replies. It does not seem to be maintained anymore.

Best regards
Peter

Flags: needinfo?(p4fg)

Fixed in 67 via bug 1252831. Should be in today's morning nightly.

On balance, I'm not convinced we want to uplift this to 66 beta, though I could be persuaded. The migration version was the same between nightly and beta prior to this bug so from that perspective it is at least possible... Thoughts, Dan?

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(dveditz)
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67

3rd party services aren't formally covered by our bounty program but we'd like to offer a small one as our thanks.

Flags: sec-bounty?
Flags: sec-bounty+
Flags: needinfo?(dveditz)

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

On balance, I'm not convinced we want to uplift this to 66 beta,

I agree, it's low severity. Anyone actually using 30boxes as their calendar is pretty insecure already and we can't fix that.

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

3rd party services aren't formally covered by our bounty program but we'd like to offer a small one as our thanks.

I would sure appreciate it. However, what you are writing does note correspond with public information about your security bug bounty program https://www.mozilla.org/en-US/security/bug-bounty/:

(Second bullet point under General Eligibility): "We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla."

Firefox being shipped with 30-boxes pre-installed as a webcal-handler would i my opinion be exactly what "third-party websites utilized by Mozilla" is all about, I hope you agree!

Best regards
Peter

The only other handlers we have in en-US are for yahoo mail, gmail and mibbit for irc/ircs. They're all maintained and relatively new/modern so I'm not worried about those much. Note maybe bug 1494105 (functionality issue, not security related) for yahoo mail...

I filed bug 1526890 to deal with the fact that some of our other locales have some http: (non-TLS) links.

Other than that, off-hand they look like they're for major companies - mostly Google, Yahoo, Yandex, Microsoft, sometimes "just" in their locale - e.g. onet.pl is big in Poland (cf. https://www.alexa.com/topsites/countries/PL )but probably not well-known in the US), so I'm less worried about maintainability. I'm not the right person to do a full audit for XSS in their respective links, also because all of the webmail ones are behind auth portals and require accounts etc. In any case, given that they're not places where I think we'd struggle finding a contact to just actually fix any XSS or other web security issues, I don't think there's any others that need to be removed.

Flags: needinfo?(gijskruitbosch+bugs)
Group: firefox-core-security → core-security-release
Flags: qe-verify+
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][post-critsmash-triage]

Updated the link in comment #0 to a URI-escaped one which still shows the XSS (as I was momentarily confused as to whether it got fixed by 30boxes - seems it still hasn't...).

This issue is still reproducible for me too. Could you please tell me if there is anything else that will be fixed in this bug, or intended to fix the issue in another bug? Thanks.

(In reply to Timea Zsoldos [:zstimi/tzsoldos], Desktop Release QA from comment #18)

This issue is still reproducible for me too. Could you please tell me if there is anything else that will be fixed in this bug, or intended to fix the issue in another bug? Thanks.

We should have removed the 30 boxes app as an option for webcal links. That should be verifiable, and should be done in bug 1252831 (where the patches for that landed).

Flags: needinfo?(timea.zsoldos)

I have reproduced this issue using Firefox 66.0a1 (2019.01.08) on Ubuntu 18.04 x64, Win 10 x64 and macOS 10.13.6 follow the test case:

  1. The prefs by default:
    gecko.handlerService.schemes.webcal.0.name; 30 Boxes
    gecko.handlerService.schemes.webcal.0.uriTemplate; https://30boxes.com/external/widget?refer=ff&url=%s
  2. Paste into the URL : webcal://www.mozilla.org?q=<script>document.location='http://redirected.shellcode.se';</script>
  3. Firefox asks if you want to open the link with the application "30 Boxes", then shows the message "You have been maliciously redirected to this page..."

I verified using Firefox 67.0b10 on Win 10 x64, macOS 10.13.6 and Ubuntu 18.04 x64, the two prefs are:
gecko.handlerService.schemes.webcal.0.name; chrome://browser-region/locale/region.properties
gecko.handlerService.schemes.webcal.0.uriTemplate; chrome://browser-region/locale/region.properties

This time Firefox doesn't asks if you want to open the link with the application "30 Boxes" and doesn't shows the message.

Based on comment #17 if I paste into URL the link: https://30boxes.com/external/widget?refer=ff&url=www.mozilla.org?q=webcal%3A%2F%2Fwww.mozilla.org%3Fq%3D%3Cscript%3Edocument.location%3D%27http%3A%2F%2Fredirected.shellcode.se%27%3B%3C%2Fscript%3E
the message "You have been maliciously redirected to this page..." shows.

vs Chrome : "This page isn’t working" ... ERR_BLOCKED_BY_XSS_AUDITOR page opened.

Flags: needinfo?(timea.zsoldos)

(In reply to Timea Zsoldos [:zstimi/tzsoldos], Desktop Release QA from comment #20)

Based on comment #17 if I paste into URL the link: https://30boxes.com/external/widget?refer=ff&url=www.mozilla.org?q=webcal%3A%2F%2Fwww.mozilla.org%3Fq%3D%3Cscript%3Edocument.location%3D%27http%3A%2F%2Fredirected.shellcode.se%27%3B%3C%2Fscript%3E
the message "You have been maliciously redirected to this page..." shows.

Yes, this is the XSS vulnerability in the webpage which we have no way of fixing.

vs Chrome : "This page isn’t working" ... ERR_BLOCKED_BY_XSS_AUDITOR page opened.

Yes, this is Chrome's XSS auditor, which attempts to spot XSS-type content in URLs. We don't have such a feature; there's some background in bug 528661 comment 56 as to why not.

Anyway, based on the rest of your comment I think we can mark this verified.

Status: RESOLVED → VERIFIED
Summary: XSS in the default protocol-handler for webcal → Remove the default protocol handler for webcal given it has serious XSS vulnerabilities
Flags: qe-verify+
Keywords: sec-low
Whiteboard: [reporter-external] [client-bounty-form] [verif?][post-critsmash-triage] → [reporter-external] [client-bounty-form] [verif?][post-critsmash-triage][adv-main67+]
Alias: CVE-2019-11701

The bug-bounty hall-of-fame have not been updated in quite a while, last entries was Q1 2018?
https://www.mozilla.org/en-US/security/bug-bounty/hall-of-fame/

Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: