1427289 - (CVE-2018-5171) Executing JS on addons.mozilla.org using webRequestBlocking

Status: VERIFIED FIXED

(WebExtensions :: Request Handling, defect, P2)

Description

[Abdulrahman Alqabandi]

Attachment: POC.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36

Steps to reproduce:

1. Install attached PoC




Actual results:

https://addons.mozilla.org is opened and then using browser.webRequest.filterResponseData we filter the script loading of google-analytics injecting it with our own code.


Expected results:

Usually when you mention "<all_urls>" within the manifest permission you still can't execute JS on the addons website, but for some reason webRequest doesn't perform this check.

Comment 1

[Andy McKay]

If we are going to keep blocking content scripts on AMO we should probably restrict filterResponseData as well.

Comment 2

[Frederik Braun [:freddy]]

Kris, this sec-high bug hasn't been moving for a while and its actionable.
Can you give us an update here on next steps and timeline?

Thanks!

Comment 3

[Frederik Braun [:freddy]]

David, can you help us re-prioritize the work on this bug?
If kmag is too busy, maybe someone else can take this?

Comment 4

[Kris Maglione [:kmag]]

This will be fixed by bug 1415644.

Comment 5

[Abdulrahman Alqabandi]

I can confirm this bug doesn't seem to work anymore on latest build after bug 1415644 was fixed.

Comment 7

[Kris Maglione [:kmag]]

At this point, the original reasons for blocking extension scripts on AMO no longer hold. The original prohibition was mainly due to the fact that the mozAddonManager API allowed it to install extensions without any user confirmation. The current API only allows the ability to list installed extensions, and to install without the second xpinstall whitelist prompt.

At this point, I think this bug should be rated sec-moderate at best, at least as far as AMO is concerned. As far as its relationship to bug 1415644 is concerned, if that bug is sec-high and the bug allowed extensions to bypass the same restrictions for those sites, I suppose this bug should be treated as sec-high too.

I can't say for sure whether I would have fixed that loophole in the process of fixing bug bug 1415644 if this bug hadn't been filed. Although I suspect that in the process of fixing bug 1444539, at least, I would have.

Comment 9

[Abdulrahman Alqabandi]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #7)
> At this point, the original reasons for blocking extension scripts on AMO no
> longer hold. The original prohibition was mainly due to the fact that the
> mozAddonManager API allowed it to install extensions without any user
> confirmation. The current API only allows the ability to list installed
> extensions, and to install without the second xpinstall whitelist prompt.

There seems to be an exception somewhere to this rule.

on testpilot domain we can execute the following:

navigator.mozAddonManager.createInstall({
            url: "https://testpilot.firefox.com/files/@testpilot-addon/signed-addon.xpi"
        }).then(function(e){e.install().then(function(){})})

and the 'legacy' addon is installed automatically. I wonder if this bug could be hypothetically used to intercept the XPI, but probably not since I have no idea how the signing and verification methods work. Will test later (unless someone with more knowledge tells me its impossible)

Comment 10

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi from comment #9)
> (In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're
> blocked) from comment #7)
> > At this point, the original reasons for blocking extension scripts on AMO no
> > longer hold. The original prohibition was mainly due to the fact that the
> > mozAddonManager API allowed it to install extensions without any user
> > confirmation. The current API only allows the ability to list installed
> > extensions, and to install without the second xpinstall whitelist prompt.
> 
> There seems to be an exception somewhere to this rule.
> 
> on testpilot domain we can execute the following:
> 
> navigator.mozAddonManager.createInstall({
>             url:
> "https://testpilot.firefox.com/files/@testpilot-addon/signed-addon.xpi"
>         }).then(function(e){e.install().then(function(){})})
> 
> and the 'legacy' addon is installed automatically. I wonder if this bug
> could be hypothetically used to intercept the XPI, but probably not since I
> have no idea how the signing and verification methods work. Will test later
> (unless someone with more knowledge tells me its impossible)

Andrew, can you clarify what's going on here?

Comment 11

[Andrew Swan [:aswan]]

(In reply to Abdulrahman Alqabandi from comment #9)
> (In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're
> blocked) from comment #7)
> > At this point, the original reasons for blocking extension scripts on AMO no
> > longer hold. The original prohibition was mainly due to the fact that the
> > mozAddonManager API allowed it to install extensions without any user
> > confirmation. The current API only allows the ability to list installed
> > extensions, and to install without the second xpinstall whitelist prompt.
> 
> There seems to be an exception somewhere to this rule.

We never showed pre-install confirmations for legacy extensions, this was an explicit decision from product (or UX?), we had some back-and-forth about it but they were pretty firm.  We do show a post-install notification for legacy extensions.
Of course, legacy extensions need to be specially signed to run on release or beta, there are a dwindling number of these that still exist and we should be down to zero some time this year.  And nightly/devedition users who have flipped the extensions.legacy.enabled preference may still install legacy extensions.  But again, if somebody did manage to exploit this, they could only install a signed legacy extension from AMO and the user would still see a post-install notification.

> I wonder if this bug
> could be hypothetically used to intercept the XPI, but probably not since I
> have no idea how the signing and verification methods work. Will test later
> (unless someone with more knowledge tells me its impossible)

Well feel free to poke at it, but if if you manage to modify the XPI and not break the signature verification in the process, that would be a separate bug with the signing system.

Comment 12

[Abdulrahman Alqabandi]

(In reply to Andrew Swan [:aswan] from comment #11)
> if somebody did manage to exploit this, they
> could only install a signed legacy extension from AMO and the user would
> still see a post-install notification.

Which can easily be circumvented via webextension api's by closing the tab or window (and opening a new one).

Comment 13

[Kris Maglione [:kmag]]

I still wouldn't rate this more than sec-moderate at this point.

The original problem was that an extension could be installed with few-to-no visible permissions and then silently install another extension (possibly created by the same author) to get whatever elevated privileges it wanted. At this point, any WebExtension with elevated privileges would trigger a permission prompt that the user would have to accept.

A Mozilla-signed legacy extension would not trigger a permission prompt, but there are only a few of those in existence, they can't be generally created, and they don't trigger permission prompts on install, anyway. Having an extension silently install them is annoying, but not a serious privilege escalation.

If you can find a Mozilla-signed extension that would allow a WebExtension to gain elevated privileges when installed, I may reconsider, but for now, I still consider this bug only moderate.

Comment 14

[Emil Ghitta, QA [:emilghitta]]

I have managed to reproduce this issue using Firefox 59.0a1 (BuildId:20171228220110).

This issue is verified fixed using Firefox 61.0a1 (BuildId:20180503220110) and Firefox 60.0 (BuildId:20180430165945) on Windows 10 64bit , macOS 10.13.3 and Ubuntu 16.04 64bit.