Bug 1427289 (CVE-2018-5171)

Executing JS on addons.mozilla.org using webRequestBlocking

VERIFIED FIXED in Firefox 60

Status

P2
normal
VERIFIED FIXED
a year ago
4 months ago

People

(Reporter: qab, Assigned: kmag)

Tracking

({csectype-priv-escalation, sec-moderate})

58 Branch
mozilla60
csectype-priv-escalation, sec-moderate
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(firefox-esr52 wontfix, firefox59 wontfix, firefox60 verified, firefox61 verified)

Details

(Whiteboard: [adv-main60+])

Attachments

(1 attachment)

1.91 KB, application/x-zip-compressed
Details
(Reporter)

Description

a year ago
Posted file 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.

Updated

a year ago
Component: Untriaged → WebExtensions: Request Handling
Product: Firefox → Toolkit

Comment 1

a year ago
If we are going to keep blocking content scripts on AMO we should probably restrict filterResponseData as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Keywords: sec-high

Updated

a year ago
Assignee: nobody → kmaglione+bmo
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!
Flags: needinfo?(kmaglione+bmo)
David, can you help us re-prioritize the work on this bug?
If kmag is too busy, maybe someone else can take this?
Flags: needinfo?(ddurst)
Group: firefox-core-security → toolkit-core-security
(Assignee)

Comment 4

a year ago
This will be fixed by bug 1415644.
Flags: needinfo?(kmaglione+bmo)
(Reporter)

Comment 5

a year ago
I can confirm this bug doesn't seem to work anymore on latest build after bug 1415644 was fixed.
(Assignee)

Updated

a year ago
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(ddurst)
Resolution: --- → FIXED
status-firefox59: --- → wontfix
status-firefox60: --- → fixed
status-firefox-esr52: --- → wontfix
Target Milestone: --- → mozilla60
Flags: sec-bounty?
(Assignee)

Comment 7

a year ago
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.
(Reporter)

Comment 9

a year ago
(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

a year ago
(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?
Flags: needinfo?(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.
Flags: needinfo?(aswan)
(Reporter)

Comment 12

a year ago
(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).
(Assignee)

Comment 13

a year ago
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.
Flags: sec-bounty? → sec-bounty+
Keywords: sec-high → csectype-priv-escalation, sec-moderate
Group: toolkit-core-security → core-security-release
Whiteboard: [adv-main60+]
Alias: CVE-2018-5171
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.
Status: RESOLVED → VERIFIED
status-firefox60: fixed → verified
status-firefox61: --- → verified

Updated

9 months ago
Product: Toolkit → WebExtensions
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.