This patch displays the new telemetry field "loadStatus", which was introduced
by the earlier patch, on about:support. With this information, a user can see
each of injected modules was really loaded or blocked by our DLL blocklist.
Differential Revision: https://phabricator.services.mozilla.com/D102409
We used to record a DLL loading event only when a module was loaded.
With this patch, we record an event for a module blocked by our DLL
blocklist as well as a loaded module. It is achieved by calling
to `ModuleLoadFrame::NotifySectionMap` in `patched_NtMapViewOfSection`
regardless of the block action.
This patch introduces a new member `ModuleLoadInfo::mStatus` and
`ProcessedModuleLoadEvent::mLoadStatus` to keep the DLL loading status,
which will be added to the third-party-modules ping by a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D102407
This patch displays the new telemetry field "loadStatus", which was introduced
by the earlier patch, on about:support. With this information, a user can see
each of injected modules was really loaded or blocked by our DLL blocklist.
Differential Revision: https://phabricator.services.mozilla.com/D102409
We used to record a DLL loading event only when a module was loaded.
With this patch, we record an event for a module blocked by our DLL
blocklist as well as a loaded module. It is achieved by calling
to `ModuleLoadFrame::NotifySectionMap` in `patched_NtMapViewOfSection`
regardless of the block action.
This patch introduces a new member `ModuleLoadInfo::mStatus` and
`ProcessedModuleLoadEvent::mLoadStatus` to keep the DLL loading status,
which will be added to the third-party-modules ping by a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D102407
Thunderbird does not yet have the same blocklist initialization as Firefox, so we skip calling InitDllBlocklistOOP to avoid a MOZ_RELEASE_ASSERT.
Differential Revision: https://phabricator.services.mozilla.com/D99173
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
We blocked the older versions of database.dll as Bug 1566109 in 2019,
but the same crash is still happening with the newer versions.
We decided to block all versions because crashing in the middle of printing
or file uploading is not acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D92988
This patch adds a new property `process_type` to the launcher process failure
ping, indicating which process type the browser process failed to initialize
as a sandboxed process.
Depends on D83639
Differential Revision: https://phabricator.services.mozilla.com/D83640
This patch adds winlauncher's HandleLauncherError to DllServices
along with InitializeDllBlocklistOOPInternal so that SandboxBroker
can call HandleLauncherError.
Differential Revision: https://phabricator.services.mozilla.com/D83639
When the osclientcerts module attempts to use client certificates and keys from
certain tokens, the Windows APIs will attempt to load asepkcs.dll. If Firefox
blocks this library, the keys won't be available. Thus, it needs to be
unblocked.
Due to the architecture of osclientcerts (namely, its dedicated single thread),
using asepkcs.dll via the Windows APIs shouldn't cause the crashes that led to
this module being blocked.
Differential Revision: https://phabricator.services.mozilla.com/D82788
`nscore.h` includes `xpcom-config.h` which need not be generated for
non-XPCOM consumers. In additon, `nullptr` and `bool` are C++
keywords, so at least some of the comments were dated.
The added include lines address transitive consumers of `nscore.h`.
Differential Revision: https://phabricator.services.mozilla.com/D82640
`BLOCK_WIN8_ONLY` was introduced by bug 1268470 to block klsihk64.dll only on
Win8. However, a new blocklist (bug 1445025) does wrong comparison on the OS
version, thus `BLOCK_WIN8_ONLY` has blocked modules on all platforms older than
Win10 including Win7 and Win8.1.
This patch corrects OS comparison and changes the flag to `BLOCK_WIN8_AND_OLDER`
to make it more handy. We also remove `BLOCK_WIN8PLUS_ONLY` which is never used.
Differential Revision: https://phabricator.services.mozilla.com/D78411
Also update documentation to suggest using the `GeneratedFile` template rather than directly referencing `GENERATED_FILES` where possible.
Differential Revision: https://phabricator.services.mozilla.com/D77496
When the browser process starts a sandbox process, we copy the executable's IAT
for ntdll.dll into the new process to prevent DLL injection via IAT tampering as
the launcher process does. However, if IAT has been modified by a module injected
via `SetWindowHookEx`, the browser process cannot copy IAT because a modified IAT
is invalid in a different process, failing to start any sandbox processes.
The proposed fix is to cache IAT before COM initialization which may load
modules via `SetWindowHookEx` for the first time in the process.
Differential Revision: https://phabricator.services.mozilla.com/D73303
With ASAN, GTest uses the old blocklist implemented in mozglue, where
the new blocklist type `RedirectToNoOpEntryPoint` behaves the same as
`DllBlocklistEntry`. The test needs to expect `LoadLibrary` to fail.
Differential Revision: https://phabricator.services.mozilla.com/D70578
--HG--
extra : moz-landing-system : lando
This patch introduces a new DLL blocklist type `RedirectToNoOpEntryPoint`
which hooks a DLL's entrypoint into a no-op function. With this technique,
we give the injected DLL no chance to run its code though we allow it to be
loaded into the process.
This new blocklist type is intended to block a DLL which is injected by IAT
patching which was planted by a kernel callback routine for LoadImage. It's
because blocking such a DLL makes a new process fail to launch.
Differential Revision: https://phabricator.services.mozilla.com/D68348
--HG--
extra : moz-landing-system : lando
This patch introduces a new DLL blocklist type `RedirectToNoOpEntryPoint`
which hooks a DLL's entrypoint into a no-op function. With this technique,
we give the injected DLL no chance to run its code though we allow it to be
loaded into the process.
This new blocklist type is intended to block a DLL which is injected by IAT
patching which was planted by a kernel callback routine for LoadImage. It's
because blocking such a DLL makes a new process fail to launch.
Differential Revision: https://phabricator.services.mozilla.com/D68348
--HG--
extra : moz-landing-system : lando
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--HG--
extra : moz-landing-system : lando
The blocklist variable `BROWSER_PROCESS` did not work as expected. Entries
defined there were blocked not only in the browser process but also in the
child process.
This patch makes sure entries in `BROWSER_PROCESS` are blocked only in the
browser process.
Differential Revision: https://phabricator.services.mozilla.com/D65248
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando