Intent to harden binary injection by removing XPCOM and related xul.dll exports

[Benjamin Smedberg]

This is notice of an intent to change how we export symbols from the
Firefox DLLs and binaries.

Currently our policy is that extensions may not include binary XPCOM
components, and we've implemented some very basic rules that make it
difficult for extensions to load these components. However, there is
3rd-party software that continues to use binary XPCOM: either by loading
DLLs using ctypes and then using XPCOM, or injecting DLLs into the Firefox
process.

Binary injection has been the cause of numerous crash issues in Firefox,
which commonly show up as startup crashes when a Firefox update is first
run. I believe that solving these crashes is a critical part of our Firefox
quality story and our ability to release Firefox updates in a timely manner.

To that end, I believe that we should make it technically impossible for
external DLLs to use XPCOM. I propose to do this in the following way:

Integrate the remaining Firefox binary component back into xul.dll using
internal linkage.

Remove the XPCOM glue. This will involve reworking a little bit of how
firefox.exe and plugin-container.exe initially load and launch gecko from
xul.dll.

Remove most of the XPCOM-related xul.dll exports, and as many other exports
as possible.
This includes all of the mozilla::services exports, as well as things like
NS_GetComponentManager/NS_GetComponentRegistrar, and a lot of the XRE_
functions like XRE_AddManifestLocation.

Undecided: whether we can or need to remove the "frozen XPCOM string API"
exports. I'd like to, but it's not strictly necessary to solve the primary
stability issues of external code using binary XPCOM, and I'm not sure what
it would affect or how hard it will be.

I have prepared a list of current xul.dll exports from a recent nightly
build, and proposed mitigations with bug numbers:
https://docs.google.com/spreadsheets/d/1k2tFvEetMri2MT7viBM9iSVVt35dQH8O_mmNkYX9NOc/edit?usp=sharing

It is likely that this project will affect Thunderbird and/or SeaMonkey,
but I'm not sure in what ways. My understanding is that Thunderbird
currently builds with internal linkage. I plan to keep Thunderbird informed
of the work here, and accepting patches that help Thunderbird stay
building, but I do not intend to significantly delay or WONTFIX this
Firefox work for Thunderbird.

https://bugzilla.mozilla.org/show_bug.cgi?id=1299187 is the tracking bug.

Please direct followup comments & questions to dev-platform.

--BDS

[Gregory Szorc]

On Tue, Aug 30, 2016 at 8:44 AM, Benjamin Smedberg <benj...@smedbergs.us>
wrote:

To clarify, are you proposing a) removing all support for exporting XPCOM
symbols from libxul full stop or b) changing the shipping configuration of
Firefox to not export these symbols?

[Benjamin Smedberg]

On Tue, Aug 30, 2016 at 12:16 PM, Gregory Szorc <g...@mozilla.com> wrote:

>
> To clarify, are you proposing a) removing all support for exporting XPCOM
> symbols from libxul full stop or b) changing the shipping configuration of
> Firefox to not export these symbols?
>

b) is the minimum option for Firefox.

I think a) is the better option, and I'd like to try it: assuming I'm right
about thunderbird using internal linkage, I don't see any reason we need to
keep exporting these symbols at all.

--BDS

[R Kent James]

On 8/30/2016 8:44 AM, Benjamin Smedberg wrote:

> It is likely that this project will affect Thunderbird and/or SeaMonkey,
> but I'm not sure in what ways. My understanding is that Thunderbird
> currently builds with internal linkage. I plan to keep Thunderbird informed
> of the work here, and accepting patches that help Thunderbird stay
> building, but I do not intend to significantly delay or WONTFIX this
> Firefox work for Thunderbird.

Thunderbird 45 (based on m-esr45) has allowed binary extensions, but we
have agreed for some months now that Thunderbird 52 will no longer
support binary extensions. The extensions are currently only used by
addons closely closely connected to the core project. Even at TB 45
there were significant changes in m-c that made using a binary extension
very challenging, and the assumption has been that ongoing changes, such
as the ones you are suggesting here, would make that impossible. I am
not aware of any existing parts of shipping Thunderbird that use
external linkage, but if there are any that would be something that
needs removing or fixing.

That being said, there has been some pushback on this due to the
performance costs of using JS instead of C++. If major breaking changes
could be delayed until Gecko 53, or if it was possible to have some
build options that would allow external linkage as an option, that would
be good. But we could live without it.

:rkent

[Mike Hommey]

On Tue, Aug 30, 2016 at 11:44:35AM -0400, Benjamin Smedberg wrote:
> This is notice of an intent to change how we export symbols from the
> Firefox DLLs and binaries.
>
> Currently our policy is that extensions may not include binary XPCOM
> components, and we've implemented some very basic rules that make it
> difficult for extensions to load these components. However, there is
> 3rd-party software that continues to use binary XPCOM: either by loading
> DLLs using ctypes and then using XPCOM, or injecting DLLs into the Firefox
> process.
>
> Binary injection has been the cause of numerous crash issues in Firefox,
> which commonly show up as startup crashes when a Firefox update is first
> run. I believe that solving these crashes is a critical part of our Firefox
> quality story and our ability to release Firefox updates in a timely manner.
>
> To that end, I believe that we should make it technically impossible for
> external DLLs to use XPCOM. I propose to do this in the following way:
>
> Integrate the remaining Firefox binary component back into xul.dll using
> internal linkage.

If we do this, we could as well reconsider the separation of browser and
GRE files. Firefox is the only gecko-based application that does it. It
was introduced for the metro UI, used by the webapp runtime, and was
useful to ensure xulrunner toolkit files weren't trying to use Firefox
files through resource://gre. None of metro, webapprt or xulrunner are
a thing anymore. There's still a risk for toolkit using resource://gre
urls for Firefox resources, though, and that can impact
Thunderbird/Seamonkey/other third-party XUL apps.

> Remove the XPCOM glue. This will involve reworking a little bit of how
> firefox.exe and plugin-container.exe initially load and launch gecko from
> xul.dll.

With all the stuff repeated between various nsBrowserApp.cpp-like files,
with different level of support for the latest things in non-Firefox,
this is more than welcome. That's something that I've been meaning to do
for a long while, but this never reached a high enough priority to make
it out of my TODO.

> Remove most of the XPCOM-related xul.dll exports, and as many other exports
> as possible.
> This includes all of the mozilla::services exports, as well as things like
> NS_GetComponentManager/NS_GetComponentRegistrar, and a lot of the XRE_
> functions like XRE_AddManifestLocation.
>
> Undecided: whether we can or need to remove the "frozen XPCOM string API"
> exports. I'd like to, but it's not strictly necessary to solve the primary
> stability issues of external code using binary XPCOM, and I'm not sure what
> it would affect or how hard it will be.

If there aren't XPCOM binary components, I don't see what difference it
would make if the XPCOM string API is exported or not. In fact, it could
be removed, nothing should be using it through internal linkage.
(And here, I really mean not-built, since it might be necessary to keep
for comm-central)

Mike

[Ehsan Akhgari]

On 2016-08-30 11:44 AM, Benjamin Smedberg wrote:
> This is notice of an intent to change how we export symbols from the
> Firefox DLLs and binaries.
>
> Currently our policy is that extensions may not include binary XPCOM
> components, and we've implemented some very basic rules that make it
> difficult for extensions to load these components. However, there is
> 3rd-party software that continues to use binary XPCOM: either by loading
> DLLs using ctypes and then using XPCOM, or injecting DLLs into the
> Firefox process.
>
> Binary injection has been the cause of numerous crash issues in Firefox,
> which commonly show up as startup crashes when a Firefox update is first
> run. I believe that solving these crashes is a critical part of our
> Firefox quality story and our ability to release Firefox updates in a
> timely manner.
>
> To that end, I believe that we should make it technically impossible for
> external DLLs to use XPCOM.

Can you please clarify why this proposal is around preventing external
DLLs from using XPCOM? In my experience, a good number of the DLLs
different programs inject into Firefox are injected using the several
facilities that Windows provides for this task, and whether or not those
DLLs get access to the symbols currently exported from xul.dll, they can
still cause a lot of harm. I'm trying to understand how removing the
XPCOM functions they can link against dynamically will improve our
situation.

Thanks,
Ehsan

[Brunoais]

Does team viewer's quick connect button continue working in firefox
windows after that?

On 30-08-2016 16:44, Benjamin Smedberg wrote:
> This is notice of an intent to change how we export symbols from the
> Firefox DLLs and binaries.
>
> Currently our policy is that extensions may not include binary XPCOM
> components, and we've implemented some very basic rules that make it
> difficult for extensions to load these components. However, there is
> 3rd-party software that continues to use binary XPCOM: either by
> loading DLLs using ctypes and then using XPCOM, or injecting DLLs into
> the Firefox process.
>
> Binary injection has been the cause of numerous crash issues in
> Firefox, which commonly show up as startup crashes when a Firefox
> update is first run. I believe that solving these crashes is a
> critical part of our Firefox quality story and our ability to release
> Firefox updates in a timely manner.
>
> To that end, I believe that we should make it technically impossible

> for external DLLs to use XPCOM. I propose to do this in the following way:
>
> Integrate the remaining Firefox binary component back into xul.dll
> using internal linkage.
>

> Remove the XPCOM glue. This will involve reworking a little bit of how
> firefox.exe and plugin-container.exe initially load and launch gecko
> from xul.dll.
>

> Remove most of the XPCOM-related xul.dll exports, and as many other
> exports as possible.
> This includes all of the mozilla::services exports, as well as things
> like NS_GetComponentManager/NS_GetComponentRegistrar, and a lot of the
> XRE_ functions like XRE_AddManifestLocation.
>
> Undecided: whether we can or need to remove the "frozen XPCOM string
> API" exports. I'd like to, but it's not strictly necessary to solve
> the primary stability issues of external code using binary XPCOM, and
> I'm not sure what it would affect or how hard it will be.
>

> I have prepared a list of current xul.dll exports from a recent
> nightly build, and proposed mitigations with bug numbers:
> https://docs.google.com/spreadsheets/d/1k2tFvEetMri2MT7viBM9iSVVt35dQH8O_mmNkYX9NOc/edit?usp=sharing
>

> It is likely that this project will affect Thunderbird and/or
> SeaMonkey, but I'm not sure in what ways. My understanding is that
> Thunderbird currently builds with internal linkage. I plan to keep
> Thunderbird informed of the work here, and accepting patches that help
> Thunderbird stay building, but I do not intend to significantly delay
> or WONTFIX this Firefox work for Thunderbird.
>

> https://bugzilla.mozilla.org/show_bug.cgi?id=1299187 is the tracking bug.
>
> Please direct followup comments & questions to dev-platform.
>

> --BDS
>
>
> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

[Benjamin Smedberg]

On Tue, Aug 30, 2016 at 6:08 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

>
> Can you please clarify why this proposal is around preventing external
> DLLs from using XPCOM? In my experience, a good number of the DLLs
> different programs inject into Firefox are injected using the several
> facilities that Windows provides for this task, and whether or not those
> DLLs get access to the symbols currently exported from xul.dll, they can
> still cause a lot of harm. I'm trying to understand how removing the
> XPCOM functions they can link against dynamically will improve our
> situation.
>

I'm working on that larger problem also. With the shipping of native
messaging in webextensions, we may be able to make a policy that extensions
and other addon-type software should not load DLLs into the Firefox
process. I'm currently discussing the implications and implementation
strategies of that with the addons team. This would however primarily be a
policy and addon-signing question: we don't have a good way to actively
block these DLLs.

This proposal here is a technical step we can take which will immediately
make things better. I've investigated several of the addon-related startup
crashes that have caused us to delay or respin releases or block particular
DLLs or addons over the past six months. Almost all of those crashes were
related to the addon using XPCOM and being hit by some binary-incompatible
change along the way.

--BDS

[Ehsan Akhgari]

On 2016-08-31 9:27 AM, Benjamin Smedberg wrote:
>
>
> On Tue, Aug 30, 2016 at 6:08 PM, Ehsan Akhgari <ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>> wrote:
>
>
> Can you please clarify why this proposal is around preventing external
> DLLs from using XPCOM? In my experience, a good number of the DLLs
> different programs inject into Firefox are injected using the several
> facilities that Windows provides for this task, and whether or not those
> DLLs get access to the symbols currently exported from xul.dll, they can
> still cause a lot of harm. I'm trying to understand how removing the
> XPCOM functions they can link against dynamically will improve our
> situation.
>
>
> I'm working on that larger problem also. With the shipping of native
> messaging in webextensions, we may be able to make a policy that
> extensions and other addon-type software should not load DLLs into the
> Firefox process. I'm currently discussing the implications and
> implementation strategies of that with the addons team. This would
> however primarily be a policy and addon-signing question: we don't have
> a good way to actively block these DLLs.

That sounds like a great idea! Especially if we end up revoking the
signatures of add-ons which violate this policy. I'd be looking forward
to see what comes out of that effort also.

> This proposal here is a technical step we can take which will
> immediately make things better. I've investigated several of the
> addon-related startup crashes that have caused us to delay or respin
> releases or block particular DLLs or addons over the past six months.
> Almost all of those crashes were related to the addon using XPCOM and
> being hit by some binary-incompatible change along the way.

Makes sense. Thanks for the clarification!

[Benjamin Smedberg]

As of this morning the important guts of this work have landed to
mozilla-central and should ride the Firefox 53 trains. Here are the
technical details, for those interested:


- The only XPCOM function intentionally exported from libxul is
XRE_GetBootstrap. This function may be called once to get a class that
allows firefox, xpcshell, plugin-container, etc to start.
- The remaining guts of gecko are no longer exported: mozilla::Services,
NS_InitXPCOM, NS_GetComponentManager and all the rest are internal-only.
- There are a few helper functions for OS.File which are exported, which
is not a problem in terms of blocking 3rd-party code.
- The dependent XPCOM glue static library (xpcomglue_s) no longer exists.
- The standalone XPCOM glue library (xpcomglue) still exists, with the
sole purpose of loading libxul and calling XRE_GetBootstrap.

I want to publicly thank Mike Hommey, Eric Rahm, and Nathan Froyd for
helping with a bunch of tedious conversion/refactoring work to get this
reviewed and landed!

I intend to file a bug for us to stop shipping and building the Mozilla SDK.

Mike and I are both working on some cleanup work after this: rearranging
the files in xpcom/glue as well as making our startup code and sequence
less crazy and spread across many files and directories.

--BDS

On Tue, Aug 30, 2016 at 11:44 AM, Benjamin Smedberg <benj...@smedbergs.us>

wrote:

> This is notice of an intent to change how we export symbols from the
> Firefox DLLs and binaries.
>
> Currently our policy is that extensions may not include binary XPCOM
> components, and we've implemented some very basic rules that make it
> difficult for extensions to load these components. However, there is
> 3rd-party software that continues to use binary XPCOM: either by loading

> DLLs using ctypes and then using XPCOM, or injecting DLLs into the Firefox
> process.
>

[Nicholas Nethercote]

Hooray! This change prevents a significant cause of crashes.

Nick

On Fri, Jan 20, 2017 at 2:47 AM, Benjamin Smedberg <benj...@smedbergs.us>