Bugzilla

Comment 1

•

9 years ago

As mentioned via Email, we can't really do anything sensible about this from our side. The only option we have is to use an app-global install instead of the distribution install, but there are various reasons why this ended up not being feasible. See https://calendar.etherpad.mozilla.org/thunderbird-integration for details. The most important reasons are that that install locations is being deprecated, and we cannot upgrade Lightning users that have a profile-installed Lightning to an app-global installed Lightning.

I'd suggest filing a more general bug about this in Toolkit :: Add-ons Manager or bringing this up on the mozilla.apps.user-experience newsgroup. As we've determined, the problem doesn't only exist for binary components, but also for dll's opened from JS extensions in %APPDATA% using ctypes. Given Firefox has disallowed binary extensions this might be a valuable argument.

Reporter

Comment 2

•

9 years ago

Of course you can do something about this, and you have some alternatives:
1. dont bundle your (or ANY other extension with TB or FX): until now FX doesnt come with extensions preinstalled, and TB just started to do so;
2. if you bundle an extension with TB or FX then install it app-global (until the Mozilla platform ensures the safety and security for extensions).
Generally you MUST NOT impair the safety and security of your users!

The "most important reasons" are NOT important here:
1. people who have Lightning installed already are used to upgrade it themselves;
2. the decision to declare app-global installation of extensions is shortsighted, since profile-local installation is a security/safety nightmare.

Comment 3

•

9 years ago

(In reply to Stefan Kanthak from comment #2)
> Of course you can do something about this, and you have some alternatives:
> 1. dont bundle your (or ANY other extension with TB or FX): until now FX
> doesnt come with extensions preinstalled, and TB just started to do so;
I don't see how this is an alternative. Just turn off the feature?


> 2. if you bundle an extension with TB or FX then install it app-global
> (until the Mozilla platform ensures the safety and security for extensions).
> Generally you MUST NOT impair the safety and security of your users!
So before, Lightning was installed via addons manager in the profile, in the same place it is now, with the same security merits. Now, we bundle Lightning and it is also installed into the profile. The only difference is that we bundle it, security has not changed. Users that do not like Lightning are presented with a bar that will allow them to disable it.

That aside, if malware has access to the computer, it can install an arbitrary extension into the profile, which contains a binary component, which can be called just the same. There is no reason to put the burden for this on Lightning just because it is installed with Thunderbird. 


> 
> The "most important reasons" are NOT important here:
> 1. people who have Lightning installed already are used to upgrade it
> themselves;
Right, and on each major release there are NUMEROUS complaints that updates are not working, resulting in support requests and bad reviews. Bundling Lightning with Thunderbird removes the need for manual updates and we can make certain that the user has the right version installed. 

> 2. the decision to declare app-global installation of extensions is
> shortsighted, since profile-local installation is a security/safety
> nightmare.
If you mean declaring them deprecated, this is not our decision. If you have a complaint about this please direct it towards the Toolkit folks making such statements.

There is also the problem that on each app-global installed addon, a warning appears on first startup prompting to install Lightning. The wording makes it sound like the addon has been installed from another source and is not to be trusted.


While I admire your sense of security, I think you are barking at the wrong tree here. Profile installed add-ons are a generally accepted pattern within Mozilla, just as are distribution extensions. app-global add-ons are on the chopping block and don't provide the same user experience advantages. If you can change this situation in the Toolkit component, we are certainly open to adapting to these changes.

Reporter

Comment 4

•

9 years ago

> So before, Lightning was installed via addons manager in the profile,
> in the same place it is now, with the same security merits.

It was but ONLY installed upon user's choice.
Now you preinstall and activate it per default for ALL users.

> Now, we bundle Lightning and it is also installed into the profile.

of every user. That's the difference.

> The only difference is that we bundle it, security has not changed.

Right.
Security is as bad as before, but now this affects ALL users of TB.

> Users that do not like Lightning are presented with a bar that will
> allow them to disable it.

That's wrong too: they should be asked whether the bundled extension
should be installed in the first place, and it should be disabled
until the user explicitly enables it.

> While I admire your sense of security, I think you are barking at
> the wrong tree here.

No.
Before TB 38 there was no extension distributed and installed by TB.

Again: until Mozilla does not provide safety and security for
extensions you MUST NOT distribute and install any with Mozilla products.

> Profile installed add-ons are a generally accepted pattern within Mozilla,

So Mozilla apparently doesn't care about their customers safety and security.

Feel free to send this bug report to the Toolkit.

Wayne Mery (:wsmwk)

Updated

•

9 years ago

Component: Internal Components → Add-ons Manager

Product: Calendar → Toolkit

Dave Townsend [:mossop]

Comment 5

•

9 years ago

(In reply to Stefan Kanthak from comment #0)
> TB (and of course FX too) must not run tampered code, neither from a DLL nor
> a .JS, or prevent tampering.
>
> The simplest solution: install extensions in %ProgramFiles%

This is actually far from simple, it would either require the application to run as a privileged application or request windows activation for every addon install or update. The likely outcome of that is that either users don't actually install or update add-ons in a timely fashion or they become blind to the activation prompt and reduce their safety.

> Installation of extensions in %APPDATA% is a security and safety NIGHTMARE.

If some tool is able to overwrite a DLL in your profile folder then you've already lost the security game, said tool can also just run arbitrary code anyway. That said there are a couple of features that have already been implemented that add roadblocks to this use case.

We've implemented extension signing requirements in Firefox which will reduce the possibility of running untampered code. Firefox is also choosing to disable support for binary xpcom components in add-ons.

I don't think Thunderbird is opting into either of these features but since they are implemented and available it doesn't make sense to keep this bug open in Toolkit.

Component: Add-ons Manager → Internal Components

Product: Toolkit → Calendar

Reporter

Comment 6

•

9 years ago

> If some tool is able to overwrite a DLL in your profile folder then you've
> already lost the security game, said tool can also just run arbitrary code anyway.

Wrong assumption.
You don't need to run a dedicated "tool" to overwrite a DLL or the Javascript files of an extension.
For example it's sufficient that a (java)script loaded by a web site and running inside Firefox (or any other application which interprets scripts) is able to overwrite a component of an add-on.
In case of a DLL code written to it is then run native; in case of an XUL script the code is then run with "chrome" privileges.

> We've implemented extension signing requirements in Firefox

Are these requirements enforced?
What is to be signed?
EACH and EVERY single (XUL) script needs to be signed and their signature checked at EVERY execution.
This is but NOT the case (yet)!

Dave Townsend [:mossop]

Comment 7

•

9 years ago

(In reply to Stefan Kanthak from comment #6)
> > If some tool is able to overwrite a DLL in your profile folder then you've
> > already lost the security game, said tool can also just run arbitrary code anyway.
> 
> Wrong assumption.
> You don't need to run a dedicated "tool" to overwrite a DLL or the
> Javascript files of an extension.
> For example it's sufficient that a (java)script loaded by a web site and
> running inside Firefox (or any other application which interprets scripts)
> is able to overwrite a component of an add-on.

So you're assuming that there is a security vulnerability in Firefox that would allow a file to be overwritten but not allow process execution. I guess it's possible but you could still use such a vulnerability to automatically execute code, say by writing to the users startup entry in the start menu, no add-ons needed. I'm not aware of any such vulnerability existing and once e10s is turned on everywhere the risk of such a vulnerability existing drops dramatically. The best path for such a case is to fix the vulnerability as it would affect more than just add-ons.

> In case of a DLL code written to it is then run native; in case of an XUL
> script the code is then run with "chrome" privileges.
> 
> > We've implemented extension signing requirements in Firefox
> 
> Are these requirements enforced?

Not yet, we should be turning on enforcement shortly

> What is to be signed?
> EACH and EVERY single (XUL) script needs to be signed and their signature
> checked at EVERY execution.

Not at every execution which would be an unacceptable performance hit but when we detect any change and periodically after that.

Reporter

Comment 8

•

9 years ago

> So you're assuming that there is a security vulnerability in Firefox that
> would allow a file to be overwritten but not allow process execution.
> I guess it's possible but you could still use such a vulnerability to automatically
> execute code, say by writing to the users startup entry in the start menu, no add-ons needed.

Not necessarily, I used Firefox and javascript embedded in a web site just as an example.
Writing files in the user profile is by itself not a (security) vulnerability, but a legitimate user action.

The problem here is that executable code is installed into a user-writable location, and that the integrity of this code isn't enforced (yet)!

Now get your copy of the 20 year old "Designed for Windows" guidelines and notice their mandatory and basic requirement that applications have to be installed in %ProgramFiles%. Since only Administrators can write there the applications are tamper-protected.
TB 38 and newer come with an extension which is but installed into the (user) profile and violates this mandatory requirement.

Execution of files written to the autostart locations can be inhibited with SAFER alias software restriction policies, so on a properly secured Windows installation you clearly need add-ons to execute code.

Comment 9

•

9 years ago

Given your posts to security lists, it seems to me you are not convinced that what you describe is not an issue specific to Thunderbird and Lightning. Note that other Mozilla products also use the profile to install shipped extensions, or such are downloaded on demand. If users are paranoid about this, they are free to uninstall all add-ons and disable the install locations.

I am not yet convinced that the addon subsystem can be used for a remote code execution attack. You mentioned websites using Javascript to write into the profile folder, but said this was just an example and it doesn't hold since website js can not overwrite addons. Aside from through a specific security bug in the product, I don't see how a website could overwrite add-on code in a way that it can be used to execute remotely injected code. Maybe you have a better example for this case?

Regarding local code execution, as Dave mentioned, there are far more interesting things malware can do if it has filesystem access to the user profile. You mention that certain actions can be locked down with restriction policies. If such policies have been instated on a user's machine, it should be simple to add an additional rule for the extensions directory. Such lockdown policies are usually only applied on enterprise user machines or by power users. Therefore, on a properly locked down environment it is simple to add protection against installing extensions, and enterprise maintainers can pre-install addons into the app-global location as required. If the environment is not locked down, there are much more lucrative places to drop malware for local code execution.

Also, that there are far more .dlls in the %APPDATA% folder by other products. Dropbox, Openoffice, Amazon Music, Chromecast, Chrome extensions, Google Updater, just to name a few. Despite guidelines created 20 years ago, it looks to me like in 2015 it is common practice to do so.

Reporter

Comment 10

•

9 years ago

(In reply to Philipp Kewisch [:Fallen] from comment #9)
> Given your posts to security lists, it seems to me you are not convinced
> that what you describe is not an issue specific to Thunderbird and
> Lightning.

Which part of "starting with TB 38 Lightning is installed and activated
by default" is SO hard to understand.
Before TB 38 NO extension was preinstalled, so TB 38 changed the playground.

> Note that other Mozilla products also use the profile to install
> shipped extensions, or such are downloaded on demand.

Right. ALL Mozilla products share this same BAD habit.
They but dont ship extensions.

> If users are paranoid about this, they are free to uninstall all add-ons

Unfortunately only TB installs an add-on per default.

> and disable the install locations.

The other way 'round should be the default: ONLY secure install locations
should be enabled per default, and users who nevertheless want to install
extensions in insecure locations MUST be warned and give the consent,
explicitly!

> I am not yet convinced that the addon subsystem can be used for a remote
> code execution attack.

The installation of executable code in user-writable locations allows but
RCE: as soon as only ONE application installed on the users computer allows
to overwrite an extensions files the damage is done.

> You mentioned websites using Javascript to write into
> the profile folder, but said this was just an example and it doesn't hold
> since website js can not overwrite addons. Aside from through a specific
> security bug in the product, I don't see how a website could overwrite
> add-on code in a way that it can be used to execute remotely injected code.
> Maybe you have a better example for this case?

DEFENSE IN DEPTH!

> Regarding local code execution, as Dave mentioned, there are far more
> interesting things malware can do if it has filesystem access to the user
> profile. You mention that certain actions can be locked down with
> restriction policies. If such policies have been instated on a user's
> machine, it should be simple to add an additional rule for the extensions
> directory.

Both SAFER and AppLocker restrict execution through the Win32-API, i.e.
CreateProcess*() and LoadLibrary*(), plus ShellExecute*() and the various
scripting engines which Windows installs.
It does but NOT restrict execution of JavaScript in Mozilla or any other
application. Mozilla (or any other application) can but implement an
interface to SAFER or AppLocker and can thus opt-in to SAFER or AppLocker
too.

> Such lockdown policies are usually only applied on enterprise
> user machines or by power users.

Right. So ALL your home users are left unprotected.

> Therefore, on a properly locked down
> environment it is simple to add protection against installing extensions,
> and enterprise maintainers can pre-install addons into the app-global
> location as required. If the environment is not locked down, there are much
> more lucrative places to drop malware for local code execution.
> 
> Also, that there are far more .dlls in the %APPDATA% folder by other
> products.

Right. CRAPWARE exists.

> Dropbox, Openoffice, Amazon Music, Chromecast, Chrome extensions,
> Google Updater, just to name a few.

Right. All these are CRAPWARE, and a security nightmare too!

> Despite guidelines created 20 years ago, it looks to me like in 2015
> it is common practice to do so.

It is BAD practice and an EVIL habit.
Do you really want to join this "club"?

Comment 11

•

9 years ago

(In reply to Stefan Kanthak from comment #10)
> (In reply to Philipp Kewisch [:Fallen] from comment #9)
> > Given your posts to security lists, it seems to me you are not convinced
> > that what you describe is not an issue specific to Thunderbird and
> > Lightning.
> 
> Which part of "starting with TB 38 Lightning is installed and activated
> by default" is SO hard to understand.
> Before TB 38 NO extension was preinstalled, so TB 38 changed the playground.
Sure, now we have a pre-installed extension, but this doesn't change anything about the general issue you mention. The problem is not with Thunderbird shipping Lightning, but from your perspective with the addon system in general.


> 
> > Note that other Mozilla products also use the profile to install
> > shipped extensions, or such are downloaded on demand.
> 
> Right. ALL Mozilla products share this same BAD habit.
> They but dont ship extensions.
The OpenH264 plugin is installed the same way, the DRM component for EME is to be rolled out the same way. You now mention what I am trying to convey, it is not an issue with TB shipping Lightning, but from your description affects the whole addon system. Looking at the media reaction to your posts, this has not come across.


> The installation of executable code in user-writable locations allows but
> RCE: as soon as only ONE application installed on the users computer allows
> to overwrite an extensions files the damage is done.
So then a local program is overwriting an addon, and it is no longer a remote attack.

> > Maybe you have a better example for this case?
> 
> DEFENSE IN DEPTH!
Huh? (Also, please stop using all caps for those single words in between. This is very rude.)

>  Mozilla (or any other application) can but implement an
> interface to SAFER or AppLocker and can thus opt-in to SAFER or AppLocker
> too.
Sounds like a separate bug to me.

> Right. All these are CRAPWARE, and a security nightmare too!
I wouldn't consider all this software crapware just because of the dlls in appdata. The software works quite well and does what it is supposed to. 

Anyway, I don't have the feeling we are going to come to an agreement, so I will retract myself from this discussion. You still haven't provided a concrete example on how a remote attack would look like and have not proven me wrong that for local attacks there are more interesting things that malware can do with user account access. I understand that having dlls in a user-writable location may provide hooks for malware, but I don't see why Mozilla addons would be at higher risk than other software. I also don't see the severity of the risk, to mind mind there are no remote exploitation mechanisms and there are enough malware protection solutions to cover the local case.
agree to your perception that the big problem is that Thunderbird ships Lightning.

For a constructive discussion, I think you should rather contribute a suggestion on how to solve the UX issues that arise when installing into the application directory, mentioned at the beginning of comment 5.

Comment 12

•

9 years ago

> agree to your perception that the big problem is that Thunderbird ships Lightning.
Please disregard this half-sentence, it seems I forgot to delete it.

Reporter

Comment 13

•

9 years ago

(In reply to Philipp Kewisch [:Fallen] from comment #11)

> > Which part of "starting with TB 38 Lightning is installed and activated
> > by default" is SO hard to understand.
> > Before TB 38 NO extension was preinstalled, so TB 38 changed the playground.
> Sure, now we have a pre-installed extension, but this doesn't change
> anything about the general issue you mention. The problem is not with
> Thunderbird shipping Lightning, but from your perspective with the addon
> system in general.

As long as the add-on system uses user-writable locations to install
extensions and does NOT provide any means to prevent execution of
modified code you simply MUST NOT install any extension.
TB 38 is just the first Mozilla product which but does so.

DONT sacrifice ALL your users security/safety, but let them choose
1. where to install add-ons,
2. whether to install add-ons at all,
3. whether to activate which add-ons.

> 
> > The installation of executable code in user-writable locations allows but
> > RCE: as soon as only ONE application installed on the users computer allows
> > to overwrite an extensions files the damage is done.
> So then a local program is overwriting an addon, and it is no longer a
> remote attack.

Wrong. And THINK!
As soon as some local program which can write to the user profile can be
controlled remotely (this may be intended but also unintended) this becomes
an RCE.

> > DEFENSE IN DEPTH!
> Huh?

Yes. See above.

> (Also, please stop using all caps for those single words in between.
> This is very rude.)

Wrong.
Delivery of applications which put users at (avoidable) risk is RUDE!

> > Right. All these are CRAPWARE, and a security nightmare too!
> I wouldn't consider all this software crapware just because of the dlls in
> appdata. The software works quite well and does what it is supposed to. 

plus it provides a well-known attack vector!

> For a constructive discussion, I think you should rather contribute a
> suggestion on how to solve the UX issues that arise when installing into the
> application directory, mentioned at the beginning of comment 5.

Which UX problems exist in the update process of TB or FX?
Use the SAME process for add-ons too.

Reporter

Comment 14

•

9 years ago

What's the difference between CVE-2014-4495 alias mfsa2015-78 and this bug
which allows to "inject script into the privileged part of any installed add-on"?

<https://www.mozilla.org/en-US/security/advisories/mfsa2015-78/> says:

| Security researcher Cody Crews reported on a way to violate the same origin
| policy and inject script into a non-privileged part of the built-in PDF Viewer.

Flags: needinfo?(daniel.veditz)

Comment 15

•

9 years ago

Should probably have used "context" instead of "part". Nothing is written to the disk: the JavaScript is injected into a frame used internally by the PDF Viewer and inherits that frame's origin (the non-privileged resource:// which is equivalent to file:// ). 

There's no point in singling out calbasecomps.dll. Replacing the XUL/JS bits of Lighting (or any add-on) would lead to the same end result. For example, Firefox was hacked at Pwn2Own this year by an exploit that ran its payload as pure privileged JavaScript, no binary code.

Flags: needinfo?(daniel.veditz)

Summary: Arbitrary (local or remote) code execution in calbasecomps.dll → Overwriting Lightning in the profile could lead to arbitrary code execution

Updated

•

9 years ago

Summary: Overwriting Lightning in the profile could lead to arbitrary code execution → Overwriting any addon in the profile could lead to arbitrary code execution

Reporter

Comment 16

•

9 years ago

(In reply to Daniel Veditz [:dveditz] from comment #15)
> Should probably have used "context" instead of "part". Nothing is written to
> the disk: the JavaScript is injected into a frame used internally by the PDF
> Viewer and inherits that frame's origin (the non-privileged resource://
> which is equivalent to file:// ). 

This is but only ONE difference ... or should I say similarity: the others are
* CVE-2015-4495 is not persistent, but this bug is a persistent threat;
* CVE-2015-4495 is an RCE, while this bug is an LCE ... until another bug (not
  necessarily in a Mozilla product) allows to overwrite local files;
* CVE-2015-4495 is a now fixed bug leading to an unintended vulnerability,
  while this bug is a principal and intended vulnerability/weakness;
* ...

> There's no point in singling out calbasecomps.dll.

Correct. This was just my starting point because it allows direct/immediate
execution of native x86 code, while JavaScript running privileged as chrome://
needs to use js-ctypes first.

JFTR: in case you've heard of Raymond Chen you may want to read his opinion.

http://blogs.msdn.com/b/oldnewthing/archive/2010/11/11/10089223.aspx

| Also, per-user application installation needs execute permission on the
| user profile. (It is my understanding that these "creative methods" are
| themselves vulnerabilities, so removing execute from %TEMP% is a defense
| in depth issue rather than a primary defense measure.)

Reporter

Comment 17

•

9 years ago

Now that Firefox ESR 31.8.0 reached end-of-life and all newer versions of
Firefox ship with OpenH264 which installs gmpopenh264.dll into the profile
and enables it per default ALL current versions Firefox are vulnerable too!

Al Billings [:abillings - ex-MoCo]

Reporter

Comment 18

•

9 years ago

From <https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/>

| We’re responsible for our add-ons ecosystem and we can’t sit idle as our users suffer due to bad add-ons.

EVERY add-on which is installed in an unsafe location and can be tampered is a BAD add-on!

Updated

•

9 years ago

Group: core-security

Flags: sec-bounty?

Updated

•

9 years ago

Group: core-security → core-security-release

Kent James (:rkent)

Comment 19

•

9 years ago

From a practical Mozilla perspective, is extension signing an acceptable response to this? Does that prevent the OpenH264 issue from comment 17?

Reporter

Comment 20

•

9 years ago

(In reply to Kent James (:rkent) from comment #19)
> From a practical Mozilla perspective, is extension signing an acceptable
> response to this? Does that prevent the OpenH264 issue from comment 17?

This would only cure the symptom (and might even be circumvented), not the cause of this problem!
Installing code in user-writable locations is generally a (design) error.

Comment 21

•

9 years ago

Unhiding the bug because the basic issue has been published on Full-disclosure (maybe not the specific Thunderbird/calendar bit) and it's a disagreement about threat model.

Group: core-security-release

Updated

•

9 years ago

Status: UNCONFIRMED → NEW

Ever confirmed: true