Closed Bug 1410073 Opened 6 years ago Closed 6 years ago

Load user32.dll immediately after the DLL Blocklist is in place.

Categories

(Core :: Security: Process Sandboxing, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox58 --- fixed

People

(Reporter: bobowen, Assigned: bobowen)

References

Details

(Whiteboard: sb+)

Attachments

(1 file)

When using an alternate desktop as part of the process sandbox, some anti-virus products are triggering bug 1400637.

This happens when the AV injects a thread early on, which causes user32.dll to load on that thread because it has not loaded already.
This causes HWND creation later in start-up to fail.

To try and mitigate this we will load user32.dll as early as possible just after the DLL blocklist has been put in place

I have reproduced the content crash on Nightly with one AV and cannot reproduce it with this change.
This is to reduce the chance of it being loaded on an injected thread.
Attachment #8920139 - Flags: review?(aklotz)
Whiteboard: sb+
Could you explain this a bit further to me, please? Why isn't user32.dll loaded during process creation?
That is perhaps an unfair question. Come to think of it, I have encountered that before as well and even modified some code to expect it!

It's probably because of the way we set the subsystem bits on firefox.exe.
Comment on attachment 8920139 [details] [diff] [review]
Load user32.dll immediately after the DLL Blocklist is in place

Review of attachment 8920139 [details] [diff] [review]:
-----------------------------------------------------------------

OK.
Attachment #8920139 - Flags: review?(aklotz) → review+
Pushed by bobowencode@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/09bd837dd61e
Load user32.dll immediately after the DLL Blocklist is in place. r=aklotz
You need to log in before you can comment on or make changes to this bug.