1244131 - Locale packs can escalate privileges via chrome URI override

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Nicolas Golubovic]

Locale packs can override chrome URIs in their manifest file. Thus, they elevate privileges from a chrome://xxx/locale/ context (no access to XPCOM objects) to whatever URI they are overriding. Here is an example:

chrome.manifest:
locale    locale-privesc    addon-name    files/
override  chrome://mozapps/content/extensions/extensions.xul  chrome://locale-privesc/locale/privesc.html

This makes an extension-internal file called privesc.html appear instead of the extensions.xul whenever a user visits about:addons. Furthermore, that file has full privileges and can, for example, execute OS-level commands. I have developed actual proof of concept code showing exactly this scenario:

https://c.iceqll.eu/poc/locale-privesc/

It will override about:addons and create a file in your /tmp directory on Linux. Trusting me here is not necessary, as you can download the add-on, extract it and see for yourself.

As for the impact: I would argue that a user does not expect a locale pack to be able to execute arbitrary commands. However, the attacker would still have to lure a victim into installing it, something that the Firefox GUI strongly advises against on third party websites.

Comment 1

[Frederik Braun [:freddy]]

Given the installation warnings ("Nightly prevented this page from asking you to _install software_ …"), I'm unsure how much of a problem this is.

CCing Mossop and bsmedberg so they can hopefully provide some context.

Comment 2

[Dave Townsend [:mossop] (PTO until July 20)]

Yeah at the moment during installation we don't do anything different for locale packs compared to extensions so we're giving users the same warnings about them so I don't think this is a problem by itself. It would be nice if locale packs couldn't do anything like this but at the moment we're not working on de-escalating them.

The one risk we do have here is that we keep talking about using a nicer install flow for add-ons we think are "safe" and unless we remember about things like this we might accidentally put locales into that bucket.

Comment 3

[Daniel Veditz [:dveditz]]

This kind of thing is why we require locale packs to be signed (e.g. bug 1197876).

Kris: do we have any review bits checking that something calling itself a "locale pack" only contains locale instructions in the manifest? Ditto themes and "skin" manifest lines.

Does this bug need to be hidden? The dangers of add-ons that do something different than what their name advertises is a fundamental issue with everything downloaded over the internet.

Comment 4

[Kris Maglione [:kmag]]

(In reply to Daniel Veditz [:dveditz] from comment #3)
> This kind of thing is why we require locale packs to be signed (e.g. bug
> 1197876).

We never got a decision on that bug, so locale packs currently aren't required
to be signed.

> Kris: do we have any review bits checking that something calling itself a
> "locale pack" only contains locale instructions in the manifest? Ditto
> themes and "skin" manifest lines.

There are some automated checks, yes, but I'm not sure there are any reviewers
who know what to do with locale packs, at this point. There have been almost
none submitted since we started automatically syncing the official ones. The
only ones I know of that are regularly updated are actually packaged as
extensions, because the author wants them to override locale packages for all
locales, which we don't allow for language packs.

> Does this bug need to be hidden? The dangers of add-ons that do something
> different than what their name advertises is a fundamental issue with
> everything downloaded over the internet.

I don't think so.

Comment 5

[Daniel Veditz [:dveditz]]

If we're not requiring locales to be signed then this _is_ a bypass of the signing requirement. The warning about dangerous content doesn't deter users and has even been de-emphasized in the new UI.

Comment 6

[Nicolas Golubovic]

I would actually like to speak about this issue amongst others in a wrap-up talk about my master's thesis very soon (April). The meeting will be public (although probably not recorded). Since this will rather stay unfixed for a while, are there any concerns from Mozilla's side or am I good to go?

Comment 7

[Andrew McCreight [:mccr8]]

Can this be unhidden per comment 4? Is there anything to be done here?

Comment 8

[Andy McKay]

I really would like to fix the locale pack signing, I think that should happen.

Comment 9

[Daniel Veditz [:dveditz]]

It's known that locale packs are privileged. Perhaps not widely, but it's still true and should be OK to unhide this bug.

Comment 10

[Andrew Swan [:aswan]]

Language packs can no longer register arbitrary chrome resources