Closed Bug 1423296 Opened 3 years ago Closed 3 years ago

Firefox never fully starts when launched from network drive on Windows


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




Tracking Status
firefox-esr52 --- unaffected
firefox57 --- disabled
firefox58 + verified
firefox59 --- verified


(Reporter: handyman, Assigned: bobowen)



(Whiteboard: sb+)


(2 files)

Steps to Reproduce:

1. Mount a network drive -- I am using a shared folder from another Windows 10 machine.
2. Unzip a build of firefox into that folder.  For example, this 64-bit nightly from Dec 5, 2017 [1].
3. Run firefox.exe from the mounted drive.  If the profile window appears, select a profile.

Expected Results:
The browser window appears with the contents of about:home.

Actual Results:
The browser window appears with a tab that says "New Tab" and browser chrome is responsive.  The content portion of the window stays blank.


Seems this may be sandbox related.  When I use a zip I made locally (using mach package), I get the console window.  The last thing it shows is the attached assertion failure and stack, which starts:

Assertion failure: NS_IsMainThread(), at c:\mozilla-src\mozilla-unified\obj-64\dist\include\mozilla/ClearOnShutdown.h:102
#01: mozilla::SandboxBroker::LaunchApp (c:\mozilla-src\mozilla-unified\security\sandbox\win\src\sandboxbroker\sandboxbroker.cpp:275)
#02: mozilla::ipc::GeckoChildProcessHost::PerformAsyncLaunchInternal (c:\mozilla-src\mozilla-unified\ipc\glue\geckochildprocesshost.cpp:1020)

Also, this symptom was seen in bug 1173371.  I don't currently think its related.


Attached file callstack
jimm suggested you might want a heads up on this.
Flags: needinfo?(bobowencode)
Looks like this might be a Win 10 thing.

I can run Firefox on Win7 from a network share on Win10, but not the other way around.

Looks like gcp has already filed bug 1422053 for that assertion, so I need to fix the way I register that clean-up.
Flags: needinfo?(bobowencode)
This is being caused by MITIGATION_IMAGE_LOAD_NO_LOW_LABEL, which explains why it's Win10 only.

icacls doesn't indicate that the network files are low integrity, but if I skip that it works.
This is a bit odd given that there is also a MITIGATION_IMAGE_LOAD_NO_REMOTE.

[Tracking Requested - why for this release]:
Running Firefox from a network drive on Win10 is completely broken.
This regressed in Fx58.
Assignee: nobody → bobowencode
Priority: -- → P1
Blocks: 1314801
Attachment #8935402 - Flags: review?(jmathies) → review+
Pushed by
Don't use MITIGATION_IMAGE_LOAD_NO_LOW_LABEL when running from a network drive. r=jimm
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Comment on attachment 8935402 [details] [diff] [review]
Don't use MITIGATION_IMAGE_LOAD_NO_LOW_LABEL when running from a network drive

Approval Request Comment
[Feature/Bug causing the regression]:
Bug 1314801

[User impact if declined]:
On Windows 10 Firefox fails to load any pages when running from a network drive.

[Is this code covered by automated tests?]:
All normal content process launches go through this code, but the network drive case is not covered.

[Has the fix been verified in Nightly?]:
Yes, I have tested in the latest Nightly.

[Needs manual test from QE? If yes, steps to reproduce]:
Should be easy to do a manual test for Beta.
STR: Copy Firefox installation to a network drive and attempt to run it on Windows 10.
[List of other uplifts needed for the feature/fix]:

[Is the change risky?]:

[Why is the change risky/not risky?]:
Trivial two line change to not use the additional mitigation when running from a network drive.

[String changes made/needed]:
Attachment #8935402 - Flags: approval-mozilla-beta?
Comment on attachment 8935402 [details] [diff] [review]
Don't use MITIGATION_IMAGE_LOAD_NO_LOW_LABEL when running from a network drive

regression fix from level 4 windows sandbox, beta58+
Attachment #8935402 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I have managed to reproduce the issue mentioned in comment 0 using Firefox 59.0a1 (BuildId:20171205100345).

This issue is no longer reproducible using Firefox 59.0a1 (BuildId:20171213100213) and Firefox 58.0b11(BuildId:20171211020921) using Windows 10 64bit.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.