1292444 - add-on signing override via config-prefs.js

Status: RESOLVED DUPLICATE of bug 1455601

(Core :: AutoConfig (Mission Control Desktop), defect)

Description

[Andrew Swan [:aswan]]

Well that didn't take long, a "hack" to disable signing is circulating that involves creating a config-prefs.js file under
/Program Files/Mozilla Firefox/defaults/prefs  or
/Applications/Firefox.app/Contents/Resources/defaults/prefs

that contains:
```
pref("general.config.obscure_value", 0);
pref("general.config.filename", "config.js");
```

and then a config.js file two directories up that contains:
```
try {
  Components.utils.import("resource://gre/modules/addons/XPIProvider.jsm", {})
    .eval("SIGNED_TYPES.clear()");
} catch (ex) {
  Components.utils.reportError(ex.message);
}
```

I'm not sure what the original intent of general.config.filename was or who thought that obscure_value was adding any protection but here we go...

Comment 1

[Andrew Swan [:aswan]]

Clarification to the description for anybody who wants to reproduce, you need an extra blank line at the beginning of config.js (the config parsing code skips the first line).  I was able to reproduce with 48.0 on MacOS 10.11.

Comment 2

[Kev Needham [:kev]]

There's a secondary method as well which involves editing and repacking omni.jar - info can be found at https://gist.github.com/anonymous/a661949550a26b9522f79095f8ae2d94

Different issue, and I know we've talked about validation of omni.jar at runtime in the past, but wanted to make sure there's visibility.

k

Comment 3

[Robert Helmer [:rhelmer]]

Why does `prefs.js` allow executing arbitrary code? Seems like it should be parsed instead of executed.

Comment 4

[Robert Helmer [:rhelmer]]

Oh I see, `general.config.filename` is the "autoconfig" feature.

Comment 5

[:Gijs (he/him)]

We could disable autoconfig support except on ESR?

Comment 6

[Dave Townsend [:mossop]]

(In reply to :Gijs Kruitbosch (PTO recovery mode) from comment #5)
> We could disable autoconfig support except on ESR?

Being able to execute arbitrary chrome privileged code on demand seems pretty bad. Is this used for anything useful in the real world?

Comment 7

[Mike Kaply [:mkaply]]

Yes, this is the primary method that enterprises use to customize Firefox and it's how the CCK2 works.

We've had this discussion in other bugs.

Until we have an enterprise solution, we can't turn this off without breaking the world.

Note that this hack requires admin privileges to lay the files down. I thought we'd established that we can't do a lot once a user as agreed to that...

Comment 8

[Mike Kaply [:mkaply]]

See:

https://bugzilla.mozilla.org/show_bug.cgi?id=1205779

Comment 9

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #7)
> Note that this hack requires admin privileges to lay the files down

Only if you needed those to install Firefox to begin with...

Comment 10

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #7)
> Note that this hack requires admin privileges to lay the files down. I
> thought we'd established that we can't do a lot once a user as agreed to
> that...

You're disagreeing with your own comment in bug 1205779 comment 25, so now I'm confused. Is this actually locked down to the app dir or no?

(In reply to Mike Kaply [:mkaply] from comment #7)
> Yes, this is the primary method that enterprises use to customize Firefox
> and it's how the CCK2 works.

But both of those could just use ESR, no?

Comment 11

[Mike Kaply [:mkaply]]

> You're disagreeing with your own comment in bug 1205779 comment 25, so now I'm confused. Is this actually locked down to the app dir or no?

That comment was made when I didn't completely understand the problem. I thought the original report was that somehow these files were being laid down into the Firefox install directory without admin privileges. Once I understood what was going on, I realized that there was really nothing we could do to solve this short of removing AutoConfig support.

> But both of those could just use ESR, no?

Many companies our regular builds because we told them in the beginning not to use the ESR because it might not be around forever.

So enterprise solutions that are only on the ESR are not solutions.


Let's be clear about this hack, though. It's not being used maliciously right now. It's being used by individuals that want or need unsigned extensions.

Our unbranded builds are not something that anyone would want to use (they say Nightly everywhere and they don't update properly).

And we still have not solved for unsigned extensions in the enterprise (which we said we would).

There are still companies out there that have internal use extensions that absolutely under no circumstances can be submitted to AMO.

We need to solve for that. (Chrome did it via Group Policy.)

This whole thing points to a larger problem that we continue to ignore that is causing us to lose marketshare in education, governments, NPOs, enterprise and more. We really should just do something.

Comment 12

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #11)
> Let's be clear about this hack, though. It's not being used maliciously
> right now. It's being used by individuals that want or need unsigned
> extensions.

It seems pretty clear it's only a matter of time until it will be.

Comment 13

[Daniel Veditz [:dveditz]]

In bug 1205779 it was reported because malicious (adware) code was abusing the feature, so abusing it to evade add-on signing should be expected any day. We might want to add telemetry/FHR probes to see how widely this feature is enabled -- we might be surprised.

AutoConfig must die. We can either say "screw you" to the folks who rely on it and kill it, or come up with a better-controlled replacement and kill it, but we shouldn't just "WONTFIX" the problem and hope no one notices. Or I guess a sort of compromise (everyone unhappy) is to say it's only available on the ESR and promise we won't kill off ESR.

Comment 14

[Kris Maglione [:kmag]]

Given http://www.ghacks.net/2016/08/14/override-firefox-add-on-signing-requirement/, I think it's pretty safe to say it's been noticed.

Comment 15

[Mike Kaply [:mkaply]]

This can also be done trivially by writing a JavaScript component and dropping it into any number of the Firefox install directories, so AutoConfig is not exactly the culprit here. The culprit is a JavaScript extensible browser. There's not much we can do about that in the near term.

Kev and I had already discussed some other ways around securing AutoConfig including requiring the autoconfig file to be specified be Group Policy or MCX. Those should probably be investigated.

As far as "AutoConfig must die", the issue is access to Components from within AutoConfig. We can solve that by sandboxing Autoconfig so that only functions in prefcalls.js[1] can be called. Then any new functions for administering Firefox could be added there. We should also fix bug 1191860 since you won't be able to use Services.jsm to show alerts.

If you're going to do this, my recommendation would be that we target this at Firefox 52 (the next ESR) with lots of messaging encouraging folks that need autoconfig to move to the ESR unless we can build the Group Policy/MCX solution above before then.

But again, as I pointed out in my first statement, you don't need AutoConfig to do this.

1: https://dxr.mozilla.org/mozilla-central/source/extensions/pref/autoconfig/src/prefcalls.js

Comment 16

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #15)
> This can also be done trivially by writing a JavaScript component and
> dropping it into any number of the Firefox install directories,

Uh, but you'd need to change the chrome.manifest file as well in order for the file to be picked up, right? And this is restricted to the Firefox install dirs (doesn't work in the profile dir), which isn't the case for autoconfig...

> As far as "AutoConfig must die", the issue is access to Components from
> within AutoConfig. We can solve that by sandboxing Autoconfig so that only
> functions in prefcalls.js[1] can be called. Then any new functions for
> administering Firefox could be added there. We should also fix bug 1191860
> since you won't be able to use Services.jsm to show alerts.

This seems like it would be a simpler thing to do then writing group policy stuff, and also like it would solve more problems.

Comment 17

[Mike Kaply [:mkaply]]

> Uh, but you'd need to change the chrome.manifest file as well in order for the file to be picked up, right? And this is restricted to the Firefox install dirs (doesn't work in the profile dir), which isn't the case for autoconfig...

No, autoconfig is restricted to install directories as well. You have to create a file in defaults/pref and the CFG file itself can only live in the Firefox install directory. That's the argument I've been making all along. Once the install directory can be accessed, any number of things can be done.

That being said, there is a way to drop a Javascript component into Firefox without changing existing chrome.manifest files. Check your JavaScript console the very first time you create a profile in Firefox.

> This seems like it would be a simpler thing to do then writing group policy stuff, and also like it would solve more problems.

There's a lot of functionality that would need to be written in prefcalls. We basically need to port the CCK2 over to prefcalls.

If anyone would like to understand the various things that enterprises need Firefox to do, I'd be more than happy to do a brownbag or something.

Comment 18

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #17)
> That being said, there is a way to drop a Javascript component into Firefox
> without changing existing chrome.manifest files. Check your JavaScript
> console the very first time you create a profile in Firefox.

It's not clear to me what you mean here, and I don't have any machines that have never had a firefox profile on them, but this sounds like a bug? Can you elaborate?

> > This seems like it would be a simpler thing to do then writing group policy stuff, and also like it would solve more problems.
> 
> There's a lot of functionality that would need to be written in prefcalls.
> We basically need to port the CCK2 over to prefcalls.

Or we could accept that some of the functionality isn't something that we want to "let" people do as part of this mechanism...

Comment 19

[Mike Kaply [:mkaply]]

> It's not clear to me what you mean here, and I don't have any machines that have never had a firefox profile on them, but this sounds like a bug? Can you elaborate?

Sorry, didn't mean to be cryptic. Firefox tries to read a chrome.manifest from the Firefox install directory on startup, but it's not there. You actually see the message at any Firefox startup.

So you can drop a chrome.manifest in the Firefox install directory and it sill get read by default.

But again, changing the chrome.manifest file in browser or components.manifest in browser/components is just as easy as what folks are doing to enable Autoconfig. Disabling AutoConfig doesn't solve this problem. It just moves it.

Once someone has read access to the Firefox install directory, they can do any number of things.

> Or we could accept that some of the functionality isn't something that we want to "let" people do as part of this mechanism...

We're not letting people do them, we're letting schools, NGOs, governments, non profits and enterprises do them that need to be able to do them.

This conversation is for a different bug, but for reference, here's a list of all the things that Chrome allows administrators:

http://dev.chromium.org/administrators/policy-list-3

For Firefox to be successful in this markets, it needs to be able to do these things.

Comment 20

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #19)
> > It's not clear to me what you mean here, and I don't have any machines that have never had a firefox profile on them, but this sounds like a bug? Can you elaborate?
> 
> Sorry, didn't mean to be cryptic. Firefox tries to read a chrome.manifest
> from the Firefox install directory on startup, but it's not there. You
> actually see the message at any Firefox startup.

OK, but this is relatively easily fixable... have you filed a bug?

> But again, changing the chrome.manifest file in browser or
> components.manifest in browser/components is just as easy as what folks are
> doing to enable Autoconfig. Disabling AutoConfig doesn't solve this problem.
> It just moves it.

Depends if permissions-wise, creating new files is prevented/allowed based on the same auth/permission as modifying existing files, which they might not be, also given signature checks.

In any case, if we wanted to we could collect up all the JS components and load them from jars instead, and ensure the files are signed or match a hash we compile into firefox.exe (I mean, if we *really* want to...). Autoconfig is (currently) a recognized way of messing with this stuff, and loading magic new XPCOM components is not. If we don't want people to do the messing, we need a solution to it. Hashing up how we do JS XPCOM components isn't going to break too many people, changing autoconfig would break a not-completely-trivial number of people (at least, that seems to be what you're saying!).

> Once someone has read access to the Firefox install directory, they can do
> any number of things.

You mean write access, right? Otherwise I am confused again...

> > Or we could accept that some of the functionality isn't something that we want to "let" [actors] do as part of this mechanism...
...
> This conversation is for a different bug

Yes.

Comment 21

[Mike Kaply [:mkaply]]

> OK, but this is relatively easily fixable... have you filed a bug?

Just discovered it.

> Depends if permissions-wise, creating new files is prevented/allowed based on the same auth/permission as modifying existing files, which they might not be, also given signature checks.

I don't think that's possible on Windows is it? to separate create and modify permissions? As far as signature checks go, I thought folks had already agreed that startup signature checks of files was too expensive and wasn't going to be done.

> In any case, if we wanted to we could collect up all the JS components and load them from jars instead, and ensure the files are signed or match a hash we compile into firefox.exe (I mean, if we *really* want to...). Autoconfig is (currently) a recognized way of messing with this stuff, and loading magic new XPCOM components is not. If we don't want people to do the messing, we need a solution to it. Hashing up how we do JS XPCOM components isn't going to break too many people, changing autoconfig would break a not-completely-trivial number of people (at least, that seems to be what you're saying!).

Yes, we could. And then folks will just find another way to "fix" this. And I'm 100% sure that if we close the AutoConfig loophole, they will use the component loophole. Or the other loophole they already found (repacking omni.ja).

Maybe instead of taking this approach we need to figure out how to solve this problem better (like Chrome did with developer mode and group policy for loading non store extensions.). We're still insisting on solving this with unbranded builds. Is it possible we've made the wrong choice? (Again, discussion for another bug).

> You mean write access, right? Otherwise I am confused again...

I meant write access. Sorry. It's early here :)

Comment 22

[Mike Kaply [:mkaply]]

One more note on the creating versus modifying thing.

That could be easily solved by having a dummy firefox.cfg file that is preexists and is verified at startup.

So the autoconfig file would simply always be there, but empty in the regular case. (That's exactly what Netscape Navigator did).

Comment 23

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #21)
> > Depends if permissions-wise, creating new files is prevented/allowed based on the same auth/permission as modifying existing files, which they might not be, also given signature checks.
> 
> I don't think that's possible on Windows is it? to separate create and
> modify permissions?

From a quick web search I expect that this is possible with NTFS filesystem permissions. It's definitely possible on unix-based filesystems, so it's still something that makes a difference on OSX and Linux, where we do also ship Firefox. Whether it's important in practice, I'm not sure. Depends what our installer does and what the default permissions in our .app bundle are like, with which I'm not familiar off-hand.

In any case, for reasons indicated below there's a difference between "add some files" and "change existing files" even for the usability/durability of such exploits. Of course, in practice malware will just turn off updates anyway, so maybe this doesn't matter. :-\

> As far as signature checks go, I thought folks had
> already agreed that startup signature checks of files was too expensive and
> wasn't going to be done.

I don't know where and by whom this was agreed. I also don't know how expensive such checks would be. Maybe they were right, but just based on this comment it's hard to really respond to this concern.

> And then folks will just find another way to "fix" this. And
> I'm 100% sure that if we close the AutoConfig loophole, they will use the
> component loophole. Or the other loophole they already found (repacking
> omni.ja).

Repacking omni.ja (and patching files to run arbitrary code) is harder to do automatically, will break partial updates and will need to be redone after full updates.

I'm not interested in stopping users doing whatever they like with Firefox. I'm interested in stopping those avenues being so trivial to use that they get exploited by malware, which is surely something that this level of 'trivial' will meet - see also comment #13. At this stage, I'd probably advocate taking whatever is the quickest way to be really really sure that we require admin/wheel priv's on the machine (or make it fully impossible) to be able to bypass signing using autoconfig. Ditto for the components/manifest file bypass.

Comment 24

[Justin Dolske [:Dolske]]

(In reply to :Gijs Kruitbosch (PTO recovery mode) from comment #23)

> > And then folks will just find another way to "fix" this. And
> > I'm 100% sure that if we close the AutoConfig loophole, they will use the
> > component loophole. Or the other loophole they already found (repacking
> > omni.ja).
> 
> Repacking omni.ja (and patching files to run arbitrary code) is harder to do
> automatically, will break partial updates and will need to be redone after
> full updates.

One of the points raised when we made it harder to hijack search engines was that there can still be value in making bad-actors go through contortions, even if 100% blocking is never possible. Specifically, it shifts the optics from "just using a Firefox feature but in a way we'd prefer they didn't" to "software clearly doing something sketchy and avoiding a protection mechanism." It also makes it clearer that it's 3rd party software acting badly, and not some kind of glaring Firefox security hole.

I also agree that this bug is more interesting due to potential malware use, than for stopping people from modifying their own installs to run unsigned addons. (Although maybe it suggests our "approved" mechanisms / communication for doing so could be improved? Not sure.)

If this is being widely used by enterprises, then it's a fair request to not outright kill it overnight. We're similarly not trying to stop enterprises from modifying their own installs. But it does become a problem of balancing the desire to close a loophole with the desire to implement an alternative.

Comment 25

[Andy McKay]

Whilst this is a way to load code without having to sign an add-on per se, it isn't directly related to add-ons or the add-ons manager. For example bug 1205779 is similar.

Comment 26

[Al Billings [:abillings - ex-MoCo]]

Gijs, this is an outstanding sec-high that is getting pretty stale. Is there any way we can move this forward or get it addressed by someone?

Comment 27

[:Gijs (he/him)]

(In reply to Al Billings [:abillings] from comment #26)
> Gijs, this is an outstanding sec-high that is getting pretty stale. Is there
> any way we can move this forward or get it addressed by someone?

We need a decision taken. We have a few options, but various groups of folks are unhappy with those options, AIUI:

- do nothing. We leave users who install stuff open to exploitation. Security folks and e.g. the folks who've been working on locking down e.g. search engines are unhappy.
- remove all of autoconfig. enterprises unhappy.
- disable autoconfig except for ESR. Some enterprises unhappy, the rest of us not super pleased about leaving that gaping hole but
- something else


In bug 1205779 mkaply went with "do nothing".

Now that XUL add-ons are going away in part because we want to make this thing not possible so that people can actually do their job without breaking half the world in add-ons / enterprises whenever we change DOM/XBL/XPCOM/exposed-JS things, we should make this go away too. If enterprises need some of this stuff, then we'll have to come up with a replacement for enterprises.

Andy, can you state the webextensions team's position on adding features to allow enterprise to do what they want to do? If it's not happening there, it'll need to happen somewhere else (e.g. MSI / group policy - but one level removed from the internal layer **) or we need to accept that this feature is going to die and lots of enterprises will stop using Firefox, which would be bad. I don't think "WONTFIX and move on" is tenable.


** because that makes it a lot easier to maintain, see https://groups.google.com/d/msg/firefox-dev/WTT8b-SAtmE/qJSP-woAEAAJ:

> To me, it felt like webextensions (and before that, the SDK) were an
> attempt to have a secondary API layer that you used for add-ons, and
> your own inter-modular-code could be as unfrozen as you liked. This by
> definition means that you can't/shouldn't use said secondary API layer
> for your own stuff because then you're back to square 1 where our own
> code and add-ons share the same API layer and now everybody is sad. 

We shouldn't expose our own APIs to enterprises / external actors without any filtering (that doesn't break app signing). That is a Bad Idea and it needs to stop.

Comment 28

[Andy McKay]

(In reply to :Gijs from comment #27)
> Andy, can you state the webextensions team's position on adding features to
> allow enterprise to do what they want to do? If it's not happening there,
> it'll need to happen somewhere else (e.g. MSI / group policy - but one level
> removed from the internal layer **) or we need to accept that this feature
> is going to die and lots of enterprises will stop using Firefox, which would
> be bad. I don't think "WONTFIX and move on" is tenable.

Enterprises want to do an awful lot of things and we try to evaluate them on a case by case basis. Some of those we've been saying no to, a simple example: removing about:addons :) There will always be something that they want to do that we won't allow. We've been moving bugs that are feel are not appropriate for add-ons into the Core / Auto Config component for want of a better place to put them.

The assumption has been that in the past, these kinds of configurations have been done via an add-on because they could do almost anything. Just making the assumption that all these things should now be available via WebExtensions isn't the way to go, when a lot of them are really about changing how the browser is configured.

Comment 29

[Mike Kaply [:mkaply]]

Honestly, we still don't have concrete data on how pervasive this is in the wild.

I believe one of the asks was to use telemetry to find that out, but I don't know how easy it is to do that.

And there are other options here that I've tossed around:

1. Requiring the autoconfig.js file to be specified via Group Policy or MCX to ensure it only gets set in an enterprise environment.
2. Build an API for Autoconfig to do the most common things people need and then sandbox autoconfig. That would be part of an overarching enterprise strategy that we would need to put together.

I would argue that the benefits of autoconfig far outweigh the bad actors. But I have no data to back that up.

And as Andy pointed out, WebExtensions is no solution here. I can't think of a single thing I do in the CCK2 that can be done via WebExtensions.

Comment 30

[Florian Quèze [:florian]]

(In reply to Mike Kaply [:mkaply] from comment #29)
> Honestly, we still don't have concrete data on how pervasive this is in the
> wild.
> 
> I believe one of the asks was to use telemetry to find that out, but I don't
> know how easy it is to do that.

Is there a bug on file for this? What's difficult about it?

> 1. Requiring the autoconfig.js file to be specified via Group Policy or MCX
> to ensure it only gets set in an enterprise environment.

I remember we discussed this in London, have you filed a bug for it?

Comment 31

[Mike Kaply [:mkaply]]

> Is there a bug on file for this? What's difficult about it?

https://bugzilla.mozilla.org/show_bug.cgi?id=1226616

It's assigned to me because I own AutoConfig, but it's not on my plate or in my wheelhouse. I did some initial looking but I don't know enough about telemetry to make this happen.

> I remember we discussed this in London, have you filed a bug for it?

No, because it was just an idea. I'm not completely convinced it's the right solution here (because we don't have a sense for how many people use Group Policy and/or MCX).

Comment 32

[Kev Needham [:kev]]

(In reply to :Gijs from comment #27)
> (In reply to Al Billings [:abillings] from comment #26)
> > Gijs, this is an outstanding sec-high that is getting pretty stale. Is there
> > any way we can move this forward or get it addressed by someone?

I think the lack of action actually relegates this as something that isn't sec-high, but I am happy to take challenges to that.

> 
> We need a decision taken. We have a few options, but various groups of folks
> are unhappy with those options, AIUI:

I don't think we've seen proof of a need to take a decision thus far. It's not clear whether this is actively being exploited, and if we have more information on whether it is, that'd be really helpful. To date I've seen one add-on make use of it (which we shut down), and vulnerability we'd shut down by closing this is trivially exploitable using any drive-by installation that can twiddle files.

The decision needed is we need to decide whether this warrants any action. I haven't seen a strong argument for at this point, but concede it's a hole we can drive a truck through, and we need an alternative approach or a decision that says "no more enterprise support", which has a somewhat larger tail of implications/outcomes.

> Now that XUL add-ons are going away in part because we want to make this
> thing not possible so that people can actually do their job without breaking
> half the world in add-ons / enterprises whenever we change
> DOM/XBL/XPCOM/exposed-JS things, we should make this go away too. If
> enterprises need some of this stuff, then we'll have to come up with a
> replacement for enterprises.

This bug is mostly around whether we can support other methods for centralized configuration of Firefox, and has little to do with XUL deprecation. What we're doing with WebExtensions shouldn't be used as a rationale to remove one of the only ways to support managed environments, but I wholly agree that it's a very good rationale for looking at whether we support those environments or not. My vote is a very heavy "yes we should", with a proper implementation of group policy config support. It's something we've worked with off-and-on, and we should solidify our position on managed deployments and whether we're willing to support them first.

> I don't think "WONTFIX and move on" is tenable.

Agreed in principle, but this bug isn't about a managed desktop API, it's about whether we continue to support a method of configuring Firefox that has been used for years. From my perspective, it's "WONTFIX until we have a solution we're happy with" and until we have an alternate solution, removing autoconfig.js isn't really tenable unless we formally remove support for corp environments.

> We shouldn't expose our own APIs to enterprises / external actors without
> any filtering (that doesn't break app signing). That is a Bad Idea and it
> needs to stop.

In certain situations, I'd disagree. If the host computer is actively logged onto a Domain or Open Directory, it makes sense to take on the group policy for those domains/orgs, and potentially give elevated privs. That said, this is a little off topic, and should be discussed on its own, something mkaply, sylvestre, and I have a vested interest in making happen.

dveditz: per comment #13, should we start looking at whether this is being exploited, where possible? In parallel, we could/should offer up a safer proposal for centralized management, and outline the costs and benefits.

I don't think we can take any action on this bug until we choose to support or not support deployments. I also don't think add-ons are a viable solution, as they'd be exploitable by any add-on, and that's a non-starter for me.

Comment 33

[Kev Needham [:kev]]

(In reply to Florian Quèze [:florian] [:flo] from comment #30)
> Is there a bug on file for this? What's difficult about it?

Mostly that we haven't seen any evidence of it being exploited at scale. If people have ways of identifying the instances of Fx that are affected, that'd be a great place to start.

Comment 34

[:Gijs (he/him)]

(In reply to Kev Needham [:kev] from comment #32)
> (In reply to :Gijs from comment #27)
> > We need a decision taken. We have a few options, but various groups of folks
> > are unhappy with those options, AIUI:
> 
> It's
> not clear whether this is actively being exploited, and if we have more
> information on whether it is, that'd be really helpful. To date I've seen
> one add-on make use of it (which we shut down), and vulnerability we'd shut
> down by closing this is trivially exploitable using any drive-by
> installation that can twiddle files.

I don't see any way of determining how many installs are exploitable by this. If I were a malware author, the first thing I'd do is turn off telemetry and any kind of reporting we'd ship. With full chrome access they can do pretty much anything we do, which includes turning off anything we do.

Similarly (though not quite as ardently), I expect corporations to turn off any kind of "phone home" we do via telemetry or add-on or update pings, so it'll be quite difficult to get any data back to us based on the presence or otherwise of these autoconfig files.

> This bug is mostly around whether we can support other methods for
> centralized configuration of Firefox, and has little to do with XUL
> deprecation.

This ^ and this:

> > We shouldn't expose our own APIs to enterprises / external actors without
> > any filtering (that doesn't break app signing). That is a Bad Idea and it
> > needs to stop.
> 
> In certain situations, I'd disagree. If the host computer is actively logged
> onto a Domain or Open Directory, it makes sense to take on the group policy
> for those domains/orgs, and potentially give elevated privs. That said, this
> is a little off topic, and should be discussed on its own, something mkaply,
> sylvestre, and I have a vested interest in making happen.

I think we're talking about different things. Specifically, the autoconfig file allows direct and unfettered/unfiltered access to Firefox-internal code. WebExtensions, the Add-on SDK as well as group policy if/when implemented, would all filter the scope of what's possible. They'll never be exactly as powerful as this script file currently is, and that's by design and really important/useful both from a security perspective (because the impact of malicious actors through such methods is limited by whatever filter applies, e.g. the WebExtensions API surface, or the set of things we let corps. control via GPO) and from a code maintenance perspective (because I don't have to worry about breaking Treestyle TabMixPlus-v3.57 -- or MegaCorp Inc's autoconfig script).

The relation to XUL deprecation exists because if we got rid of this thing *today*, corporations could still use XUL-based add-ons to accomplish the same things. When XUL-based add-ons are gone, that won't be possible anymore, so they have no recourse unless we take active steps.

Inversely, if we get rid of XUL add-ons but keep this thing, to some degree I still won't be able to make backwards-incompatible changes without worrying about compat.

> I don't think we can take any action on this bug until we choose to support
> or not support deployments. I also don't think add-ons are a viable
> solution, as they'd be exploitable by any add-on,

We could choose to only expose certain APIs to system-wide-installed webextensions.

Comment 35

[Al Billings [:abillings - ex-MoCo]]

(In reply to Kev Needham [:kev] from comment #32)
> (In reply to :Gijs from comment #27)
> > (In reply to Al Billings [:abillings] from comment #26)
> > > Gijs, this is an outstanding sec-high that is getting pretty stale. Is there
> > > any way we can move this forward or get it addressed by someone?
> 
> I think the lack of action actually relegates this as something that isn't
> sec-high, but I am happy to take challenges to that.

I'm not sure how that has any bearing on the security rating of the issue.

We rate bugs based on severity of consequences and how likely or difficult it is to trigger the issue. Lack of action in fixing an issue has no bearing on whether it is a high or critical rated issue though, if that's what you're thinking.

Comment 36

[Daniel Veditz [:dveditz]]

Moving this over to AutoConfig since it's not an add-on manager issue per se. This will continue to be a problem until we have a replacement for enterprises using AutoConfig (unlikely given lack of investment), or a way to restrict its use to "real enterprise distributions" (e.g. requiring a group policy setting as suggested, or maybe a specific signed add-on to enable it).

Lowering the severity because it requires the ability to modify the Firefox install itself.

Comment 37

[Andrew Swan [:aswan]]

There's now a public version of this at bug 1335090.
I'm not sure how to handle duplicates while this one remains hidden.  Gijs, do we just leave the two bugs separate for now?

Comment 38

[:Gijs (he/him)]

(In reply to Andrew Swan [:aswan] from comment #37)
> There's now a public version of this at bug 1335090.
> I'm not sure how to handle duplicates while this one remains hidden.  Gijs,
> do we just leave the two bugs separate for now?

I'm not sure. Could also dupe the public one here. Dan?

Comment 39

[Daniel Veditz [:dveditz]]

Arguably since this bug started with "a hack is circulating" there was limited gain from hiding this bug. Maybe it's time to give up on that. If we decided to keep this hidden (independent re-discovery of a bug, unlikely to be further duplicated) we would normally dupe the new bug here and hide it, too. But for this issue let's just dupe it.

Comment 41

[Charles]

I just discovered this bug, and am wading through these comments, after recently getting my full Release Firefox back after discovering how to get full control of my Firefox again via this 'hack'.

(In reply to :Gijs from comment #23)
> I'm not interested in stopping users doing whatever they like with Firefox.

It sure sounds like it to use users.

> I'm interested in stopping those avenues being so trivial to use that they
> get exploited by malware, which is surely something that this level of
> 'trivial' will meet - see also comment #13. At this stage, I'd probably
> advocate taking whatever is the quickest way to be really really sure that
> we require admin/wheel priv's on the machine (or make it fully impossible)
> to be able to bypass signing using autoconfig. Ditto for the
> components/manifest file bypass.

Sounds good to me. I have no problem doing a little admin dancing to get what I want.

I just hope saner heads prevail, and you don't just unilaterally eliminate the ability to install unsigned Addons without having a replacement method in place.

I actually would prefer a formal, official, Mozilla supported way of doing this, rather than this 'hack'. But it is FAR more important to me that I get what I want.

I'm still very worried that after my 15 year long affair with it, I'm eventually going to have to find a replacement for Firefox anyway, once XUL/XPCOM Addons are completely disabled. This should never have been decided on without ALL of the hooks necessary for the many very popular Addons that currently have NO API hooks available to even attempt to rewrite them.

Providing a way for those of us who want our UI to look different from what some unknown unnamed UI guru at Mozilla wants it to be, is what makes Firefox different. It seriously looks to us old timers that you guys are bound and determined to do just that, all in the name of making your job a little easier.

Comment 42

[:Gijs (he/him)]

Given the work on enterprise policies for 60, do we intend to remove this for 60? Is that work happening here or elsewhere?

Comment 43

[Mike Kaply [:mkaply]]

We do intend to remove it (or at least sandbox it or make it ESR only), but not with 60. We need some overlap so we can see what's not in the new enterprise policies.

We should probably target it for 61 or 62.

Comment 44

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #43)
> or make it ESR only

We could do this with 60, right?

> We need some overlap so we can see what's not in the new
> enterprise policies.

... without breaking that bit.

TBH, I'm pretty confused about your response, because the enterprise list communication didn't suggest to me that the existing way of configuring things wouldn't be supported in 60. If we leave chrome-privileged autoconfig execution, that's not really true...

Comment 45

[:Gijs (he/him)]

(In reply to :Gijs from comment #44)
> TBH, I'm pretty confused about your response, because the enterprise list
> communication didn't suggest to me that the existing way of configuring
> things wouldn't be supported in 60.

Err, too many negations. I meant, the comms seemed to suggest the new policies stuff would be the only thing we'd be supporting, implicitly stating we'd be removing the older stuff, like what this bug is about.

> If we leave chrome-privileged autoconfig
> execution, that's not really true...

Comment 46

[Mike Kaply [:mkaply]]

Originally I was thinking we might leave AutoConfig around in 60 and remove it in 61/62. But I'm starting to lean the other way due to things like this (and others).

The goal is to get people that rely on AutoConfig onto ESR at 60. If enterprises need to stay on rapid release, the policy engine will mostly work for them. There will be certain hijack related things that will only work on ESR, mostly around homepage and search (primarily on Windows).

I'm working to firm up this plan now.

Comment 47

[Mike Kaply [:mkaply]]

Autoconfig is officially being Sandboxed in Firefox 62 so this will go away.