RDD process fails to start due to DLL injection into a CIG process
Categories
(Firefox :: Launcher Process, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox86 | --- | verified |
People
(Reporter: toshi, Assigned: toshi)
References
Details
Attachments
(1 file)
Bug 1620114 enabled pre-spawn CIG for the RDD process. To mitigate the compat issue that DLL Injection into a CIG-enabled process via Import Table breaks process launch, we also implemented automatic DLL injection prevention (bug 1659438), but bug 1682834 revealed Norton 360 still caused that compat issue.
Their module IPSEng64.dll is injected via Import Table, and then its entrypoint function reverts the Import Table into the original state, so that the current logic of our automatic DLL injection prevention cannot detect IPSEng64.dll was injected via Import Table. This is the same technique as Symantec does, but Symantec's module even bypasses CIG itself. Therefore Norton causes this problem while Symantec does not.
To mitigate this problem, we need a more stable way to detect Import Table tampering.
Now we disabled pre-spawn CIG in non-Nightly, so currently this happens only in Nightly.
Assignee | ||
Comment 1•4 years ago
|
||
This patch is to improve the way to detect an injected dependent module for
automatic DLL blocking (bug 1659438).
In the previous version, we created a list of dependent modules in the launcher
process and shared it with other processes via the shared section. However, it
was not compatible with third-party applications who tamper the Import Table and
revert it in the injected module's DllMain (bug 1682834) because we parsed the
Import Table in the launcher process after it was reverted.
With this patch, we check the Import Table in patched_NtMapViewOfSection
,
so we can see tampering before it's reverted. More specifically, we create
a list of dependent modules in the browser process as below.
-
The launcher process creates a section object and initializes
kernel32.dll's functions. -
The launcher process transfers a writable handle of the shared
section to the browser process. -
In the browser process, if an injected dependent module is being
mapped byNtMapViewOfSection
, we add its NT path to the shared
section and block it withREDIRECT_TO_NOOP_ENTRYPOINT
. -
The
main
function of the browser process converts the writable
handle of the shared section into a readonly handle. -
The browser process transfers a readonly handle of the shared
section to a sandbox process.
Since automatic DLL blocking may still cause a compat issue like bug 1682304,
we activate it only in Nightly for now.
Comment 3•4 years ago
|
||
Backed out for causing gtest perma failures.
Backout link: https://hg.mozilla.org/integration/autoland/rev/82c645a8b5aa238f5563cef80ba4719a045a2522
Failure log: https://treeherder.mozilla.org/logviewer?job_id=326562674&repo=autoland&lineNumber=1815
INFO - TEST-START | TestDllBlocklist.NoOpEntryPoint
[task 2021-01-13T09:18:36.656Z] 09:18:36 WARNING - TEST-UNEXPECTED-FAIL | TestDllBlocklist.NoOpEntryPoint | Value of: !!hDll
[task 2021-01-13T09:18:36.656Z] 09:18:36 INFO - Actual: false
[task 2021-01-13T09:18:36.656Z] 09:18:36 INFO - Expected: true @ /builds/worker/checkouts/gecko/mozglue/tests/gtest/TestDLLBlocklist.cpp:89
[task 2021-01-13T09:18:36.656Z] 09:18:36 WARNING - TEST-UNEXPECTED-FAIL | TestDllBlocklist.NoOpEntryPoint | Value of: !!::GetModuleHandleW(kLeafName.get())
[task 2021-01-13T09:18:36.656Z] 09:18:36 INFO - Actual: false
[task 2021-01-13T09:18:36.656Z] 09:18:36 INFO - Expected: true @ /builds/worker/checkouts/gecko/mozglue/tests/gtest/TestDLLBlocklist.cpp:90
[task 2021-01-13T09:18:36.656Z] 09:18:36 WARNING - TEST-UNEXPECTED-FAIL | TestDllBlocklist.NoOpEntryPoint | test completed (time: 2ms)
[task 2021-01-13T09:18:36.657Z] 09:18:36 INFO - TEST-START | TestDllBlocklist.BlocklistIntegrity
Assignee | ||
Comment 4•4 years ago
|
||
This failure was a good catch. I updated the patch.
Comment 6•4 years ago
|
||
bugherder |
Comment 7•4 years ago
|
||
bugherder |
Comment 8•4 years ago
|
||
Can I help verify this bug? Please provide a way to reproduce if it would be helpful to do so.
Assignee | ||
Comment 9•4 years ago
|
||
(In reply to Bodea Daniel [:danibodea] from comment #8)
Can I help verify this bug? Please provide a way to reproduce if it would be helpful to do so.
Thank you for asking. This bug is a follow-up bug to bug 1682834 to deal with a third-party application like Norton 360. Because bug 1682834 was verified, we can say this fix was also verified.
Comment 10•4 years ago
|
||
Resolving this issue as verified based on the comment above and verification done for bug 1682834. Thank you.
Description
•