776071 - Signatures of already-installed addons are not checked during loading in a secure way

Status: NEW

(Core :: Security, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Since we're loading executable code from an untrustworthy (the user's profile), we should ensure that that code hasn't been tampered with, for the same reason we install Firefox (the omnijar in particular) in C:\Program Files instead of in the user's profile.

This is a problem with lots of sub-problems. Some of them are:

1. We would need a way for all addons to become signed. My suggestion is that we should have AMO sign every addon with its own "Installed from addons.mozilla.org" certificate so that all addons are signed.

2. We would need to stop loading unsigned addons. Otherwise, the tamperer could avoid signature verification by just removing signatures.

3. We would need a way to protect the certificate database so that the tamperer could not get us to accept a signature from an "untrustworthy" CA (e.g. a CA certificate of his own creation).

4. We would need to ensure that the performance cost of the signature checking is reasonable so that startup time isn't negatively impacted.

An alternative would be to try to limit the power that addons have (i.e. sandbox addons), similarly to how Chrome seems to work. However, I think it would be difficult to create such a sandbox that is simultaneously effective at improving security while not being too restrictive of addons' capabilities.

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Brian Smith (:bsmith) from comment #0)
> Since we're loading executable code from an untrustworthy (the user's
> profile), we should ensure that that code hasn't been tampered with, for the
> same reason we install Firefox (the omnijar in particular) in C:\Program
> Files instead of in the user's profile.

I'm not convinced this is a problem, or that doing this would fix anything. Anything that can write to the profile directory can already execute code with the same permissions as what Firefox runs under. And in most cases where the profile directory is modified, it's done via an installer that has elevated permissions anyway.

As an aside, I believe there are plans to allow the installer to install to a user-writable location, if it can't get elevated permissions to write to the Program Files directory. And on OSX, the application bundle is always in a user-writable location. There's loopholes beyond just modifying the omnijar (eg, distribution bundles).


> 1. We would need a way for all addons to become signed. My suggestion is
> that we should have AMO sign every addon with its own "Installed from
> addons.mozilla.org" certificate so that all addons are signed.

See https://wiki.mozilla.org/User:Jorge.villalobos/WorkWeek2012Q2/ReviewSignatures


> 2. We would need to stop loading unsigned addons. Otherwise, the tamperer
> could avoid signature verification by just removing signatures.

This is an open question in the above page, though the question there is more in regards to installing, rather than making things tamper-resistant after installation.


> 3. We would need a way to protect the certificate database so that the
> tamperer could not get us to accept a signature from an "untrustworthy" CA
> (e.g. a CA certificate of his own creation).

If I understand this correctly, we can do this already. With app updates and hotfixes (which are really just special-cased add-ons), we require built-in certificates.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Blair McBride [:Unfocused] (Back from the dead. Mostly.) from comment #1)
> (In reply to Brian Smith (:bsmith) from comment #0)
> > Since we're loading executable code from an untrustworthy (the user's
> > profile), we should ensure that that code hasn't been tampered with, for the
> > same reason we install Firefox (the omnijar in particular) in C:\Program
> > Files instead of in the user's profile.
> 
> I'm not convinced this is a problem, or that doing this would fix anything.
> Anything that can write to the profile directory can already execute code
> with the same permissions as what Firefox runs under. And in most cases
> where the profile directory is modified, it's done via an installer that has
> elevated permissions anyway.

I agree that there is little that you can do to prevent attacks by installers with elevated permissions. However, it is definitely worthwhile to protect users against software that doesn't have elevated permissions. When Firefox runs without elevated permissions, then arbitrary code execution attacks on Firefox have the ability to install addons to Firefox. With what I am proposing (moving root cert store out of the profile directory, and verifying signatures for all addons), such attacks would not be possible.

> As an aside, I believe there are plans to allow the installer to install to
> a user-writable location, if it can't get elevated permissions to write to
> the Program Files directory. And on OSX, the application bundle is always in
> a user-writable location. There's loopholes beyond just modifying the
> omnijar (eg, distribution bundles).

I agree that, in those cases, doing this will be a lost cause. But, there's a significant security reason why we try so hard to make installations in Program Files work, and those same motivations apply here.

> See
> https://wiki.mozilla.org/User:Jorge.villalobos/WorkWeek2012Q2/
> ReviewSignatures

Cool. Note that we already implemented a lot of infrastructure, client-side and server-side, that is currently used for app signing that could "relatively easily" (ridiculous phrase, I know) be re-used for this. I would be happy to help the addons team learn about how this works.

> > 2. We would need to stop loading unsigned addons. Otherwise, the tamperer
> > could avoid signature verification by just removing signatures.
> 
> This is an open question in the above page, though the question there is
> more in regards to installing, rather than making things tamper-resistant
> after installation.

In B2G, we don't do anything regarding tamper-resistance after installation. However, that is primarily because we don't let anything run in B2G that has access to these files except B2G itself. For Android, the same reasoning applies. (Though, defense against arbitrary code execution attacks IMO warrants improving on this.) I think the motivation for tamper-resistance is stronger for desktop because so many programs have read/write access to the profile directory.

> > 3. We would need a way to protect the certificate database so that the
> > tamperer could not get us to accept a signature from an "untrustworthy" CA
> > (e.g. a CA certificate of his own creation).
> 
> If I understand this correctly, we can do this already. With app updates and
> hotfixes (which are really just special-cased add-ons), we require built-in
> certificates.

I'm not sure how effective the current "built-in cert" check is. But, I agree that it can be done.

Comment 3

[bob]

Unfortunately that is the only real defense for add-on developers -- otherwise the code can be changed to do something nefarious.

There have been discussions at security conferences where add-ons have been modified post install to gain further data. To the average user, this comes off as a shortcoming of the add-on rather than firefox. But there is nothing we can do and is really a weakness in firefox's extension architecture.

Comment 4

[Joe Siegrist]

Just another data point, Chrome is close to having this issue solved with "Extension Content Verification" available as a flag in the current release version of Chrome.  It is available in about:flags.