53 lines
2.8 KiB
Markdown
53 lines
2.8 KiB
Markdown
# Application Update Design Principles
|
|
|
|
This page lays out the principles behind the design of Application Update. These
|
|
should be kept in mind when planning future development in this component.
|
|
|
|
## Bulletproof
|
|
|
|
The updater is intended to be bulletproof, meaning that it should run
|
|
successfully even in the face of the failure of arbitrary components. This is
|
|
important because, in the case of browser breakages, update is how we would fix
|
|
the problem.
|
|
|
|
## Malware Resistance
|
|
|
|
It is not uncommon for malware to want to tamper with the browser in various
|
|
ways. It may seek to prevent the user from downloading tools to remove the
|
|
malware. It may attempt to inject ads or scams into websites or the browser
|
|
itself. We, obviously, would like to be able to defend against this. But, for us
|
|
to reach affected users, we need to be able to update. Malware authors know this
|
|
and often try to prevent the browser from updating.
|
|
|
|
Once the malware has administrator privileges, the game is lost. With these
|
|
privileges, it can freely read and modify memory used by Firefox. It can rewrite
|
|
the Firefox binary with whatever they want. There is no protecting against
|
|
malware that has already made it through the
|
|
[airtight hatchway](https://devblogs.microsoft.com/oldnewthing/20240102-00/?p=109217).
|
|
But we try to be sure that low-privileged malware is unable to prevent update.
|
|
|
|
This design principle is the primary reason why we do not allow update to be
|
|
fully disabled from within the browser. This setting must be changed via
|
|
[Policy](https://mozilla.github.io/policy-templates/#disableappupdate), which
|
|
is not writable from low-privileged processes like Firefox.
|
|
|
|
## No Third-Party Updates or Update Components
|
|
|
|
We allow for a certain amount of control of update, generally intended for use
|
|
by enterprise. This includes specifying an update server other than the default
|
|
one. But we very intentionally do not allow updates to be installed unless they
|
|
are signed by Mozilla. To allow updates from other sources would, at best,
|
|
violate the user's expectations and, at worst, allow for Firefox to be silently
|
|
replaced with malware. Since users tend to trust Firefox with data as sensitive
|
|
as their banking credentials, this could have devastating consequences.
|
|
|
|
The Windows security model generally requires an elevation of permissions for
|
|
programs such as the Firefox updater to write to the default application
|
|
directory. To make this less obtrusive for our users, we provide the Mozilla
|
|
Maintenance Service to effectively allow the user to grant the updater
|
|
persistent access to this elevation without further user action. But silently
|
|
providing access to elevation is inherently dangerous. We need to make sure that
|
|
we don't elevate something that we did not intend. To prevent this, the
|
|
Maintenance Service must only run an executable that is both properly signed by
|
|
Mozilla and identified as the updater binary.
|