1205779 - AutoConfig allows running privileged code and subverts extension signing

Status: RESOLVED WONTFIX

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

Description

[Wladimir Palant]

I'm merely forwarding an issue reported under https://forum.mozilla-russia.org/viewtopic.php?pid=694540 to Bugzilla. I didn't reproduce the issue beyond verifying it in the source code.

The forum topic describes an adware that installed some ad injection code in Firefox. Rather that installing an extension, it chose a less obvious route. It created a file c:\Program Files (x86)\Mozilla Firefox\defaults\pref\pref.js with the following contents:

  pref('general.config.filename', 'cfg');
  pref('general.config.obscure_value', 0);

It also created the file c:\Program Files (x86)\Mozilla Firefox\cfg. In this file the first line was left blank, followed up by some JavaScript code that executed with chrome privileges. So while Firefox 43 is meant to ban unsigned extensions, we have a backdoor here still allowing to run unsigned code by trivial means.

For reference, general.config.filename is meant to point to a preferences file. It is supposed to have contents of the following form:

  lockPref("network.proxy.type", 0);

However, "real" preferences files are going through a special parser (http://hg.mozilla.org/mozilla-central/file/de0e763b5210/modules/libpref/prefread.cpp) - the format is JavaScript-like but no actual JavaScript code is being executed here.

AutoConfig files are treated differently. These are loaded into a sandbox (http://hg.mozilla.org/mozilla-central/file/de0e763b5210/extensions/pref/autoconfig/src/nsReadConfig.cpp#l178), after a prefcall.js file is loaded into the same sandbox (http://hg.mozilla.org/mozilla-central/file/de0e763b5210/extensions/pref/autoconfig/src/prefcalls.js). The latter requires chrome privileges, so the AutoConfig file gets them as well.

It seems that being able to run JavaScript code in AutoConfig files is actually intended (the API extends way beyond lockPref). However, these should really execute in a sandbox without any privileges, with the API functions being implemented elsewhere.

Comment 1

[Benjamin Smedberg]

Thanks. I think kev needs to own decision-making about this, including whether to make this bug public or not. Clearly autoconfig needs to change in the future, but a lot of enterprise shops still depend on it (including the privileged-code bits), so straight-up removing it is also not the right option.

I'll follow up.

Comment 2

[Daniel Veditz [:dveditz]]

When did proxyAutoConfig get privileged? it used to support only defining a couple of proxy-like remapping functions (in addition to pref stuff). We had, and fixed, a series of sandbox-escape bugs filed in the early days by moz_bug_r_a4 -- privileged execution was definitely something we tried to prevent.

In fact, evalInSandbox() might have been invented for this specific reason, before it was used for add-ons and the like. mrbkap would probably remember.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Hey dveditz,

This isn't referring to proxy auto config (which uses something completely different now but is cut off from the rest of the JS object graph), but a different enterprise feature that I don't know anything about.

Comment 4

[Kev Needham [:kev]]

The problem as stated is a something that shouldn't be permissible. 

My understanding was that JS in AutoConfig files would only have access to the Pref APIs (http://lxr.mozilla.org/seamonkey/source/extensions/pref/autoconfig/src/prefcalls.js), and anything beyond that shouldn't work. As I understand it, following the method outlined in the referenced thread allows for fairly trivial arbitrary loading and execution of JS that runs as privileged, which is something that shouldn't be permitted.

Enterprise shops rely on autoconfig as designed, which would allow access to the pref API to manage configurations, but anything beyond pref management isn't something people should expect or rely on.

My call would be to fix this, because these files shouldn't be able to do anything other than preferences mgmt. Please let me know if I've erred in any of my understandings.


(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> Thanks. I think kev needs to own decision-making about this, including
> whether to make this bug public or not. Clearly autoconfig needs to change
> in the future, but a lot of enterprise shops still depend on it (including
> the privileged-code bits), so straight-up removing it is also not the right
> option.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Florian is this something you might take a look at? Kev mentioned you might be good for this bug. 

Nicholas, I'm also trying you, since you fixed some Preferences:Backend bugs recently, can you suggest anyone to work on this?

Comment 6

[Nicholas Nethercote [inactive]]

> Nicholas, I'm also trying you, since you fixed some Preferences:Backend bugs
> recently, can you suggest anyone to work on this?

Those bugs would have been refactoring bugs (probably relating to PLDHashTable and/or nsTHashtable) that just happened to touch preferences a little bit. I don't have any actual knowledge about the preferences module, sorry.

Comment 7

[Florian Quèze [:florian]]

(In reply to Kev Needham [:kev] from comment #4)
> The problem as stated is a something that shouldn't be permissible. 
> 
> My understanding was that JS in AutoConfig files would only have access to
> the Pref APIs
> (http://lxr.mozilla.org/seamonkey/source/extensions/pref/autoconfig/src/
> prefcalls.js), and anything beyond that shouldn't work.

If this was the case (or if we decide it should be the case), we could probably load autoconfig files the same way we load default preference files.

Currently (and more or less since the beginning), autoconfig files have also been allowed to do stuff related to LDAP, and to access environment variables. If we want to preserve these things (they make sense for enterprise cases), we do need to load this file as a javascript file.

The current implementation also allows running arbitrary privileged code. That probably didn't matter at the time, but isn't reasonable now that we want to enforce add-on signing.

> Enterprise shops rely on autoconfig as designed, which would allow access to
> the pref API to manage configurations, but anything beyond pref management
> isn't something people should expect or rely on.

Could we restrict autoconfig to ESR builds?

> My call would be to fix this, because these files shouldn't be able to do
> anything other than preferences mgmt. Please let me know if I've erred in
> any of my understandings.

Are you suggesting we should drop support for the LDAP stuff and for reading environment variable?

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #5)
> Florian is this something you might take a look at? Kev mentioned you might
> be good for this bug.

I may be able to have a look there at some point (probably not right now, but in a few weeks it seems possible). I don't expect anybody to really know this code, as it was implemented in 2001 (bug 89137) and left mostly untouched since that.

Comment 8

[Kev Needham [:kev]]

(In reply to Florian Quèze [:florian] [:flo] from comment #7)
 > > My call would be to fix this, because these files shouldn't be able to do
> > anything other than preferences mgmt. Please let me know if I've erred in
> > any of my understandings.
> 
> Are you suggesting we should drop support for the LDAP stuff and for reading
> environment variable?

No, I'm asking if it's possible to sandbox what JS can do in autoconfig files to limiting access to the Prefs API and preventing arbitrary code from accessing anything.

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

I guess if this has been around since 2001 it affects all current versions. Tracking for 43 and 44. Leaving it to Sylvestre whether to track for 42 at this point.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Another report of an autoconfig related exploit being discussed on a public forum. https://bugzilla.mozilla.org/show_bug.cgi?id=1195389

Comment 11

[Wladimir Palant]

(In reply to Kev Needham [:kev] from comment #8)
> No, I'm asking if it's possible to sandbox what JS can do in autoconfig
> files to limiting access to the Prefs API and preventing arbitrary code from
> accessing anything.

Yes, it is definitely possible, easily. The simplest approach I think would be for http://mxr.mozilla.org/mozilla-central/source/extensions/pref/autoconfig/src/prefcalls.js to create a sandbox (null principal) and expose its API functions there via Cu.exportFunction(). The C++ code should then read out the sandbox variable and load additional code (the actual autoconfig script) into this one rather than the privileged sandbox it created.

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

Mike, can you help us find ownership for this bug? Thanks.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Looks like we will release 42 with this bug too.

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Mike, needinfo-ing you in case you lost track of this from our conversation the other day.

Comment 15

[Daniel Veditz [:dveditz]]

We should _not_ release an abrupt fix for this. The sandboxing step (comment 11) is straightforward, but we have no idea whether or how many legit deployments have taken advantage of the privileges and now rely on it. "We break you in two weeks" is no good. On the other hand we need to fix this before 45 or we'll be stuck with a vulnerable ESR branch. We need a pretty full beta period on this to evaluate. If we get a fast fix we could bump it to Aurora-43, but if we don't get a fix until after the merge we should target Firefox 44 for the fix.

Comment 16

[Kev Needham [:kev]]

(In reply to Daniel Veditz [:dveditz] from comment #15)
> We should _not_ release an abrupt fix for this. The sandboxing step (comment
> 11) is straightforward, but we have no idea whether or how many legit
> deployments have taken advantage of the privileges and now rely on it. "We
> break you in two weeks" is no good. On the other hand we need to fix this
> before 45 or we'll be stuck with a vulnerable ESR branch. We need a pretty
> full beta period on this to evaluate. If we get a fast fix we could bump it
> to Aurora-43, but if we don't get a fix until after the merge we should
> target Firefox 44 for the fix.

The problem is the way this is being used is a bug, not a feature.

Dan, are you advocating not putting a fast fix on release, or ESR? (just to clarify)

Comment 17

[Mike Connor [:mconnor]]

Looping in Mike Kaply, who probably knows this code better than anyone.  Also moving to the AutoConfig component (which was created after this bug was filed).

Comment 18

[Mike Kaply [:mkaply]]

(In reply to Kev Needham [:kev] from comment #4)
> Enterprise shops rely on autoconfig as designed, which would allow access to
> the pref API to manage configurations, but anything beyond pref management
> isn't something people should expect or rely on.

This is not true.

AutoConfig files are used to do a ton of things beyond simple pref manipulation and are used extensively in this way by enterprises.

Especially with the removal of distribution/bundles this has become the only way enterprises can do any customization.

The CCK2 especially depends on the fact that AutoConfig has chrome access via JavaScript. That's how all of its functionality works.

Removing this functionality would kill Firefox in the enterprise (that's no exaggeration).

Comment 19

[Mike Kaply [:mkaply]]

And incidentally, bugs about this are already public:

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

So this does not need to be a security bug.

Comment 20

[Kev Needham [:kev]]

How it was intended to be used and how it is being used are two different things. I understand how it's being used is different from the docs, but it IS taking advantage of a bug. I'd really like to get people's thoughts of fixing on release vs. fixing on ESR. ESR I think we have more time, because it's expected to be deployed in controlled environments. Release is a very different matter.


(In reply to Mike Kaply [:mkaply] from comment #18)
> (In reply to Kev Needham [:kev] from comment #4)
> > Enterprise shops rely on autoconfig as designed, which would allow access to
> > the pref API to manage configurations, but anything beyond pref management
> > isn't something people should expect or rely on.
> 
> This is not true.
> 
> AutoConfig files are used to do a ton of things beyond simple pref
> manipulation and are used extensively in this way by enterprises.
> 
> Especially with the removal of distribution/bundles this has become the only
> way enterprises can do any customization.
> 
> The CCK2 especially depends on the fact that AutoConfig has chrome access
> via JavaScript. That's how all of its functionality works.
> 
> Removing this functionality would kill Firefox in the enterprise (that's no
> exaggeration).

Comment 21

[Mike Kaply [:mkaply]]

The "bug" has been there since Firefox 1.0, and before that Mozilla 1.0.

And again, you will completely lose pretty much all Firefox enterprise deployments here.

Please don't have a knee jerk reaction to this.

And ESR versus non ESR is not relevant. Lots of companies use regular Firefox for deployments (as they were encouraged to do when the ESR was created.) Please don't use that as as a criteria.

Comment 22

[Kev Needham [:kev]]

(In reply to Mike Kaply [:mkaply] from comment #21)
> The "bug" has been there since Firefox 1.0, and before that Mozilla 1.0.
> 
> And again, you will completely lose pretty much all Firefox enterprise
> deployments here.
> 
> Please don't have a knee jerk reaction to this.
> 
> And ESR versus non ESR is not relevant. Lots of companies use regular
> Firefox for deployments (as they were encouraged to do when the ESR was
> created.) Please don't use that as as a criteria.

It's a trivial exploit to run privileged code. How could I not? :D

Comment 23

[Kev Needham [:kev]]

(In reply to Kev Needham [:kev] from comment #22)
> It's a trivial exploit to run privileged code. How could I not? :D

And there are known exploits, per above. So that's what I'm trying to get a head around.

Comment 24

[Florian Quèze [:florian]]

(In reply to Mike Kaply [:mkaply] from comment #21)

> And again, you will completely lose pretty much all Firefox enterprise
> deployments here.

> And ESR versus non ESR is not relevant. Lots of companies use regular
> Firefox for deployments (as they were encouraged to do when the ESR was
> created.) Please don't use that as as a criteria.

Mike, the current situation is untenable. With add-on signing becoming mandatory, more abuse of the remaining ways to run privileged code without signing will appear. Do you have concrete suggestions about how we can differentiate the legitimate enterprise use cases from malware installing itself on individual users' machines?

Comment 25

[Mike Kaply [:mkaply]]

Yes, I have a concrete suggestion.

In previous versions of Netscape 4.X, the cfg file was always there and was checked at startup. For some reason this was changed to a preference.

I found a little history in this bug, although it happened after it was moved to a pref.

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

Shaver even noticed this problem, because this bug was opened and never resolved:

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

with this comment from shaver:

" Can't people just set their prefs to match that anyway?
What are we protecting against?

I'm unclear why this was moved to a pref in the first place.

It should have just been left alone.

So the solution is:

Move back to a system where the CFG file is always there and not settable via a preference. This means it can't be overwritten by a non administrator.

For this, we need to come up with a standard name for the CFG file (either mozilla.cfg for all mozilla products or firefox.cfg/seamonkey.cfg/thunderbird.cfg).

We need to notify people of this new name NOW so we can get everyone to switch to using a common name and let them know when this name will be mandatory.

We should make Firefox check for this file on startup and if it is not there, show an error. If it is, parse it. The default file will be a 0 byte file, so we'll do a simple "if .exists and if .length ==0" to avoid processing the file at startup when people aren't using it.

We also need to get bug 1191860 figured out because if there was a problem, the error popup wouldn't show on Windows.

We also need to verify that autoadmin.global_config_url can only be set via AutoConfig (not via a preference).

Comment 26

[Wladimir Palant]

(In reply to Mike Kaply [:mkaply] from comment #25)
> Move back to a system where the CFG file is always there and not settable
> via a preference. This means it can't be overwritten by a non administrator.

My understanding is that this file is being evaluated before the profile is loaded. This means that the prefs file in question has to be located within the Firefox application directory - so that a non-administrator cannot set this preference already. The problem is that the malware in question does run with administrator privileges.

Comment 27

[Mike Kaply [:mkaply]]

> My understanding is that this file is being evaluated before the profile is loaded. This means that the prefs file in question has to be located within the Firefox application directory - so that a non-administrator cannot set this preference already. 

I was thinking that you could drop files in, but not modify existing files. But you're right, this is an administrator only problem.

> The problem is that the malware in question does run with administrator privileges.

Sorry, I thought we were trying to solve a non administrator privilege problem.

If you have administrator privilege, you can just drop a component into the components directory (or do any number of other things).

Once you've given administrator privileges, your machine is owned anyway.

Comment 28

[Hector Zhao [:hectorz]]

(In reply to Mike Kaply [:mkaply] from comment #18)
> 
> Especially with the removal of distribution/bundles this has become the only
> way enterprises can do any customization.

In Fx China repack distributed by Beijing office, we used to ship a slightly modified version of Addon Installer[1] in distribution/bundles to work around bug 641746, this is now done with AutoConfig.

[1]: https://viewvc.svn.mozilla.org/vc/projects/byob/trunk/application/modules/addon_management/repack_assets/distribution/bundles/%7B04C927C9-E491-4DDC-9D45-54C145422A15%7D/

Comment 29

[Liz Henry (:lizzard) (relman/hg->git project)]

Wontfix for 43 at this point based on comment 15 and other discussion. 
Mike if you do end up landing something that you want to be in the 43 release, please let me know and we can reconsider.

Comment 30

[Florian Quèze [:florian]]

I think the next step here is to collect more data about what's going on.

I filed bug 1226616 to ensure we collect information on Telemetry about this.

I think we should also add information about this on the about:support page (bug 1195389) as this will be helpful for people trying to diagnose what's happening on a machine they are trying to clean up.

Comment 31

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Mike, is this something that will get fixed in FF44 timeframe? If not, I would like to wontfix it.

Comment 32

[Mike Kaply [:mkaply]]

No, this won't get fixed.

This is not a bug. This is the way AutoConfig is designed to work.

The only thing that should be done here is adding information to about:support that AutoConfig is being used. I think that's bug 1161266.

Comment 33

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to Mike Kaply [:mkaply] from comment #32)
> No, this won't get fixed.
> 
> This is not a bug. This is the way AutoConfig is designed to work.

Why don't we resolve this bug as invalid then? 
> 
> The only thing that should be done here is adding information to
> about:support that AutoConfig is being used. I think that's bug 1161266.

Comment 34

[Mike Kaply [:mkaply]]

Agreed

Comment 35

[Mike Kaply [:mkaply]]

This need info refuses to clear...

Comment 36

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Based on comment 32, marking Fx44 status as "unaffected" as this is by design. Please correct me if I am wrong.