1430980 - Stored XSS in resource://activity-stream/data/content/activity-stream.bundle.js line 3552

Status: RESOLVED INVALID

(Firefox :: New Tab Page, defect)

Description

[FLR]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20180103231032

Steps to reproduce:

By setting the value of the browser.aboutHomeSnippets.updateUrl to a an URL toward a malicious host (which can be done by wrting to prefs.js file see bug 1430511), one can cause the about:home page to fetch malicious HTML content which will be loaded at line 3552 of resource://activity-stream/data/content/activity-stream.bundle.js.


Actual results:

For example, setting user_pref("browser.aboutHomeSnippets.updateUrl", "http://www.evil.com"); in prefs.js will cause malicious content to be added in the about:home whenever the snippets are refreshed. 

In the about:home page one could deface the home page or access a portion of the user browsing history via top sites.

Note: Since the number of top site is limited by code in resource://activity-stream/data/content/activity-stream.bundle.js (line 1551) which is executed in the context of about:home it would suggest that the entire mozilla browsing history would be accessible from the about:home page.


Expected results:

Since it is expected that the returned content of fecthing the browser.aboutHomeSnippets.updateUrl url is HTML and that it might contains JavaScript, it would be recommended to ensure that the content is cryptographically signed from a Mozilla trusted source before loading it.

Comment 1

[Ed Lee :Mardak]

The amount of top site history available to the page is normally limited to 12 top sites. The page additionally can restrict that to show just 6 top sites by line 1551 as referenced in comment 0:
https://hg.mozilla.org/releases/mozilla-release/file/FIREFOX_57_0_RELEASE/browser/extensions/activity-stream/data/content/activity-stream.bundle.js#l1551

The ability to change prefs would typically also have the ability to access history anyway I believe, but there could be a whitelist of allowable `updateUrl`s..? k88hudson?

Comment 2

[FLR]

Here few other thing that needs to be considered :

1. Having the ability to write to a file doesn't necessarly means that you have a read access. For example, writing could be perfomed by exploiting a write-only directory traversal vulnerbility.
2. Using that approach access to history is persitant through reboot and even if, let say, the malware used to write to the prefs is cleanup. 
3. In addition to access history, one could deface login page to replace link to your bank Web site with a fake version of your bank Web site.
4. The JavaScript can interact with the about:home backend which can be used to performed privileged action. For example, using the Mozilla.UITour backend capabilities one could open the privileged about:accounts and about:preferences by respectively executing Mozilla.UITour.showFirefoxAccounts(); and Mozilla.UITour.openPreferences();. The if any of those privileged ressources is vulnerable to code injection one could perform a privilege escalation by simply having its Web page doing a window.location.href = "about:home". Moreover, if remote privilege escalation is possible simply by browing the internet, the scenario in which one could do a MITM on the default browser.aboutHomeSnippets.updateUrl should be considered (and therefore not require to write on the computer).

Comment 3

[Frederik Braun [:freddy]]

Drive-by noticing this bug.
Rating it as sec-moderate since you need another bug to make activity stream talk to a different snippets server.

Comment 4

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Just wanted to say that if this bug is predicated on writing to a preference, then we can possibly disregard this issue. Not that it _isn't_ an issue, and defense-in-depth is good in general, but the ability to write an arbitrary preference is equivalent to full control of the browser (there are many other more sensitive preferences that this one, and if an attacker has the ability to write a pref, we have basically lost at this point).

Comment 5

[Kate Hudson :k88hudson]

The existing use of innerHTML is a known downside of the existing snippets architecture that is mitigated by the new tab page running in the content process. This is being addressed with the re-architecture of this system to deliver JSON-only payloads (part of this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1432588)

I agree with Paul that taking control of the pref seems like something that would be out of the scope of a fix to this particular situation.

Comment 6

[:Gijs (he/him)]

While I agree that writing to the pref is not a high priority scenario, I'm still wondering: How hard would it be to use signing for the snippets? That's what we do for SHIELD/Normandy stuff, and AIUI it would provide a further layer of security ensuring that we only run verified code. Perhaps we could reuse some of the server-side code and/or expertise?

Comment 7

[Paul Theriault [:pauljt] (no longer reading bugmail)]

On the client-side it should be straight forward to verify, but not sure how difficult it would be to sign the content. Julien probably has a better idea. I vaguely remember discussing this- there might already be a recommendation from the original RRA for this. I'll file a new bug for signing and redirect the question to Julien. 

Signing is probably separate to this specific bug. Given comment 5, this bug is probably a wontfix/invalid.