Closed Bug 1433065 Opened 2 years ago Closed 2 years ago

Firefox 58 is not loading any pages (including about: pages)

Categories

(Core :: Security: Process Sandboxing, defect)

Product:
Core
Component:
Security: Process Sandboxing
Version:
58 Branch
Platform:
x86_64
Windows 10
Type:
defect
Priority:
Not set

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla60
Tracking Flags:
Tracking Status
relnote-firefox --- 58+
firefox58 blocking verified
firefox59 --- verified
firefox60 --- verified

People

(Reporter: registrations, Assigned: bobowen)

References

Details

(Keywords: regression, Whiteboard: [AV:AVG Version:9.0.935][AV:Microsoft Defender Exploit Protection])

Attachments

(2 files)

Make the Chromium sandbox DLL blocking Nightly only
3.80 KB, patch
jimm
: review+
lizzard
: approval-mozilla-beta+
Details | Diff | Splinter Review
Release - : Make the Chromium sandbox DLL blocking Nightly only
3.82 KB, patch
ritu
: approval-mozilla-release+
Details | Diff | Splinter Review 
Steps to reproduce:
 - Open Firefox
 - Navigate to any page (e.g https://mozilla.com or about:config)

What happens:
 - Page does not load, only showing white background.

What should happen:
 - Pages loads and displays.


This happened after the automatic update to Firefox 58.
I tried a new profile, re-installing Firefox and the newest nightly, the problem persisted. Firefox 57.0.4 does not have any problems.

I used the mozregression tool to find the problematic commit:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9ea2db5c7c86d1d0dc7d8981b3d757273469962f&tochange=b78c22aa904fb6e348046003c33f735e96651a17

None of the mentioned DLLs exist on my system (ffm.dll, ffm64dll, k7pswen.dll).
Disabling the content sandbox using "set MOZ_DISABLE_CONTENT_SANDBOX=1" stops the problem from appearing.
Has Regression Range: --- → yes
Has STR: --- → yes
Seems like a pretty critical issue.
Jim, Bob, does it ring a bell?
status-firefox58: --- → affected
status-firefox59: --- → ?
status-firefox60: --- → ?
tracking-firefox58: --- → ?
Flags: needinfo?(jmathies)
Flags: needinfo?(bobowencode)
See Also: → 1432581, 1432543
Tobias, what antivirus do you have on your machine?
Flags: needinfo?(registrations)
bug 1432581 and bug 1432543 seem to describe the same problem (strange that those didn't come up when I searched for already reported bugs before filing), I also noticed processes hanging around with problematic builds.

Antivirus is ESET Endpoint Antivirus, Version 5.0.2254.0
Flags: needinfo?(registrations)
I'm using AVG antivirus and experience the same problem.
OK, given the number of reports and the specific regression range, I'm going to change the Chromium sandbox DLL blocking to be Nightly only and uplift to Beta at least.

These were added to address a problem with the way they hook our process and sometimes cause DLLs to load on the wrong thread.
The only specific issue that we know this caused is when the Alternate Desktop is turned on, which is still Nightly only at the moment.

Depending on the scale of the problem we might decide we need this uplifting to release.
Flags: needinfo?(jmathies)
Flags: needinfo?(bobowencode)
Assignee: nobody → bobowencode
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #8945411 - Flags: review?(jmathies) → review+
Pushed by bobowencode@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/541ea4baacba
Make the Chromium sandbox DLL blocking Nightly only. r=jimm
Bob, could you please fill the uplift request so that we are ready in case/when we want to take the patch
Flags: needinfo?(bobowencode)
(In reply to Sylvestre Ledru [:sylvestre] from comment #9)
> Bob, could you please fill the uplift request so that we are ready in
> case/when we want to take the patch

Yes, although I'm going to re-land shortly, because my #if lost a variable definition that I just spotted. :-(
Flags: needinfo?(bobowencode)
Pushed by bobowencode@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7aec68e1c59a
Backed out changeset 541ea4baacba - due to missing variable in non-Nightly
https://hg.mozilla.org/integration/mozilla-inbound/rev/91fb7fed2e3b
Make the Chromium sandbox DLL blocking Nightly only. r=jimm
Comment on attachment 8945411 [details] [diff] [review]
Make the Chromium sandbox DLL blocking Nightly only

Note: patch re-landed because of a missing variable in non-Nightly, so the final patch that landed was slightly different from the one on the bug.

Landed patch applies cleanly to Beta, Release patch to follow.

Approval Request Comment
[Feature/Bug causing the regression]:
Chromium sandbox DLL blocking.

[User impact if declined]:
Affected users have a non-working browser.

[Is this code covered by automated tests?]:
The sandboxed child launch code is run in most e10s tests.

[Has the fix been verified in Nightly?]:
Fix does not affect Nightly.

[Needs manual test from QE? If yes, steps to reproduce]: 
We don't have STR, could possibly be verified in Beta by reporters.

[List of other uplifts needed for the feature/fix]:
None

[Is the change risky?]:
No

[Why is the change risky/not risky?]:
Just stops blocking AV DLLs, so same as Fx57.

[String changes made/needed]:
None
Attachment #8945411 - Flags: approval-mozilla-beta?
Comment on attachment 8945411 [details] [diff] [review]
Make the Chromium sandbox DLL blocking Nightly only

I'd like to get this into mozilla-beta before the build today for 59.0b4.
Attachment #8945411 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 8945504 [details] [diff] [review]
Release - : Make the Chromium sandbox DLL blocking Nightly only

See comment 12.
Attachment #8945504 - Flags: approval-mozilla-release?
Comment on attachment 8945504 [details] [diff] [review]
Release - : Make the Chromium sandbox DLL blocking Nightly only

We want that in release too.
Attachment #8945504 - Flags: approval-mozilla-release? → approval-mozilla-release+
Comment on attachment 8945504 [details] [diff] [review]
Release - : Make the Chromium sandbox DLL blocking Nightly only

sorry, we want that but we dont' know exactly when.
Attachment #8945504 - Flags: approval-mozilla-release+ → approval-mozilla-release?
(In reply to Sylvestre Ledru [:sylvestre] from comment #18)
> Comment on attachment 8945504 [details] [diff] [review]
> Release - : Make the Chromium sandbox DLL blocking Nightly only
> 
> sorry, we want that but we dont' know exactly when.

If you ask me, as soon as possible :). Currently I can't use FF58.
testit, what version of AVG are you using?
Flags: needinfo?(frfxtst)
Whiteboard: [AV:ESET Endpoint Antivirus, Version 5.0.2254.0][AV:AVG antivirus]
Andrei, can your team reproduce this with the last beta build (and verify if the issue then is fixed by the beta 4 build?) Thanks.
Flags: needinfo?(andrei.vaida)
I'm using AVG version 9.0.935. 
I already tried it with MOZ_DISABLE_CONTENT_SANDBOX=1 and could use FF58 then without problems. Not sure, if this is the same effect as when the patch is applied.
If you are interested, I could try beta 4, if you let me know, where I can download it.
Flags: needinfo?(frfxtst)
Hey Toblas, you mentioned "ESET Endpoint Antivirus" as your AV, but I don't see that available on the ESET site - 

https://www.eset.com/us/home/for-windows/

They offer:

ESET Smart Security Premium 
ESET Internet Security 
ESET NOD32 Antivirus 

For business customers they offer:

https://www.eset.com/us/home/buy-smb/

ESET Endpoint Protection Standard 
ESET Endpoint Protection Advanced 
ESET Secure Business 

Do you know if any of these products match the one you're running?
Flags: needinfo?(registrations)
(In reply to testit from comment #22)
> I'm using AVG version 9.0.935. 

Thanks!

> If you are interested, I could try beta 4, if you let me know, where I can
> download it.

That would be greatly appreciated, thanks!
Whiteboard: [AV:ESET Endpoint Antivirus, Version 5.0.2254.0][AV:AVG antivirus] → [AV:ESET Endpoint Antivirus, Version:5.0.2254.0][AV:AVG Version:9.0.935]
(In reply to Jim Mathies [:jimm] from comment #23)
> Hey Toblas, you mentioned "ESET Endpoint Antivirus" as your AV, but I don't
> see that available on the ESET site.

I think it's part of ESET Endpoint Protection Standard, the download for the client is here:
https://www.eset.com/us/business/endpoint-security/windows-antivirus/download/

I've updated to the latest 5.x version (since that is what we use at work), which is 5.0.2271. Problem is there as well.
My colleague reports 4 other computers at work with the same problem.

I'll try to confirm later that the AV is involved by unstalling it.
Flags: needinfo?(registrations)
See Also: → 1407766
Blocks: 1406068
(In reply to testit from comment #22)
...
> If you are interested, I could try beta 4, if you let me know, where I can
> download it.

I'll echo jimm's gratitude.
If you want to see to make sure you can reproduce on the current Beta 3 that would be great:
https://www.mozilla.org/en-GB/firefox/channel/desktop/

If you run Firefox from a command line like the following, you can create a separate profile for testing:
firefox.exe -no-remote -P
(In reply to Tobias from comment #25)
I uninstalled ESET and it did _not_ fix the problem.

Looking at Microsoft Defender Exploit Protection, System settings were default, but Firefox had 8 system overrides in place:
DEP (on), EAF (on, validate access), Mandatory ASLR (on), IAF (on), Bottom-Up ASLR (on), Sim Exec (on), Caller Check (on), Stack Pivot (on).
DEP, Mandatory ASLR and Bottom Up ASLR don't seem to cause problems.
Other settings will, to various degrees (crashes/no display problem).

I believe these settings were imported from the Microsoft Security Baseline.
(In reply to Bob Owen (:bobowen) from comment #26)
> I'll echo jimm's gratitude.
> If you want to see to make sure you can reproduce on the current Beta 3 that
> would be great:
> https://www.mozilla.org/en-GB/firefox/channel/desktop/

As I prefer a zip file over a setup.exe, I unstalled FF59b3 from here: http://ftp.mozilla.org/pub/firefox/candidates/59.0b3-candidates/build2/win32/de/. I were able to reproduce the problem.
> (In reply to Tobias from comment #25)
> I uninstalled ESET and it did _not_ fix the problem.
> 
> Looking at Microsoft Defender Exploit Protection, System settings were
> default, but Firefox had 8 system overrides in place:
> DEP (on), EAF (on, validate access), Mandatory ASLR (on), IAF (on),
> Bottom-Up ASLR (on), Sim Exec (on), Caller Check (on), Stack Pivot (on).
> DEP, Mandatory ASLR and Bottom Up ASLR don't seem to cause problems.
> Other settings will, to various degrees (crashes/no display problem).
> 
> I believe these settings were imported from the Microsoft Security Baseline.

thank you - i was chatting with another affected user yesterday who also resolved the issue by deleting all exceptions for firefox from win defender exploit protection (unfortunately he hasn't recorded what was set there in the first place).
a number of affected users seem to come from an enterprise environment as well...
For anyone running into this with AV products, if you have the cycles we would appreciate you helping out by generating a crash report for us. The generated report will contain the binary module list (dlls) loaded into your browser, which should include anything AVs inject into Firefox. This will help us get the right product in house so we can test. 

There's a command line app to trigger a crash available here - 

https://ftp.mozilla.org/pub/utilities/crashfirefox-intentionally/

which was written by one of our former engineers.
I have installed now FF59beta4 from here: http://ftp.mozilla.org/pub/firefox/candidates/59.0b4-candidates/build1/win32/en-US/. The problem seems to be fixed now.
(In reply to testit from comment #31)
> I have installed now FF59beta4 from here:
> http://ftp.mozilla.org/pub/firefox/candidates/59.0b4-candidates/build1/win32/
> en-US/. The problem seems to be fixed now.

Excellent, thanks for testing this.
(In reply to [:philipp] from comment #29)

Security Baseline can be downloaded here:
https://www.microsoft.com/en-us/download/details.aspx?id=55319 (Windows 10 Version 1709 Security Baseline.zip)
The settings are in Windows-10-RS3-Security-Baseline-FINAL\Local_Script\EP.xml

> <AppConfig Executable="firefox.exe">
>    <DEP Enable="true" EmulateAtlThunks="false" />
>    <ASLR ForceRelocateImages="true" RequireInfo="false" BottomUp="true" HighEntropy="false" />
>    <Payload EnableExportAddressFilter="true" EnableExportAddressFilterPlus="true"
>     EnableImportAddressFilter="true" EnableRopStackPivot="true" EnableRopCallerCheck="true" EnableRopSimExec="true" />
>  </AppConfig>
Whiteboard: [AV:ESET Endpoint Antivirus, Version:5.0.2254.0][AV:AVG Version:9.0.935] → [AV:ESET Endpoint Antivirus, Version:5.0.2254.0 ?][AV:AVG Version:9.0.935][AV:Microsoft Defender Exploit Protection]
thanks, i could reproduce the issue on windows 10 by just switching "Stack Pivot" to "on" for firefox.exe in the windows defender exploit protection settings. 
i got to the same regression range (bug 1412827) than you did in comment #0 & can confirm that 59.0b4 connects to pages again while 59.0b3 did not in that setup.
Blocks: 1412827
i'm tagging sumo questions that describe the symptoms from this bug under https://support.mozilla.org/en-US/questions/firefox?owner=all&tagged=bug1433065&show=all
(In reply to [:philipp] from comment #34)
Both nightly and 58 release work fine with ESET installed and the Windows Defender Exploit Protection settings customizations removed.
59.0b4 works either way.
(In reply to [:philipp] from comment #34)
> thanks, i could reproduce the issue on windows 10 by just switching "Stack
> Pivot" to "on" for firefox.exe in the windows defender exploit protection
> settings. 
> i got to the same regression range (bug 1412827) than you did in comment #0
> & can confirm that 59.0b4 connects to pages again while 59.0b3 did not in
> that setup.

Looks like marco was right, it must be the inclusion of something in the blocklist unconditionally and that conflicts with the ROP Stack Pivot.
(In reply to Bob Owen (:bobowen) from comment #37)

It's not just the Stack Pivot.

I tried all the options that are turned on in the Security Baseline:
 - Data Execution Prevention (DEP) -> Fine
 - Force Randomization for Image (Mandatory ASLR) -> Fine
 - Randomise Memory Allocations (Bottom-up ASLR) -> Fine 
 - Validate Stack Integrity (StackPivot) -> no page display
 - Validate API invocation (Caller Check) -> no page display
 - Simulate Execution (SimExec) -> no page display
 - Import Address Filtering (IAF) -> no page display
 - Export Address Filtering (EAF), with and without "validate access..." option -> Crash
the first indication from webroot users is that 59.0b4 fixes the issue for them too:
https://support.mozilla.org/en-US/questions/1201750#answer-1069680
https://support.mozilla.org/en-US/questions/1201521#answer-1069693
Windows 10 fall creators update includes manual controls for some of the features the Defender product leverages. From Toblas' xml config we have - 

DEP:
 Enable="true"
 EmulateAtlThunks="false"

ASLR:
 ForceRelocateImages="true"
 RequireInfo="false"
 BottomUp="true"
 HighEntropy="false"

Payload:
 EnableExportAddressFilter="true"
 EnableExportAddressFilterPlus="true"
 EnableImportAddressFilter="true"
 EnableRopStackPivot="true"
 EnableRopCallerCheck="true"
 EnableRopSimExec="true"

In testing these individual features on Win10 1709 (Fall Creators) I've found that every payload setting here kills Firefox content.

I downloaded the baseline config zip but didn't get the same files Toblas referenced. Still trying to figure out where these settings come from and who set them. 

Open question - is this a standard config or is this a situation where we have users in enterprise environments where the admins have over zealously set security features on Firefox? TBD.

This doesn't look wide spread so far though.
(In reply to Jim Mathies [:jimm] from comment #40)

In this case I am that administrator. The Fall Creators' Update deprecates EMET and brings those new controls.
I downloaded the "Windows 10 Version 1709 Security Baseline.zip" from the URL I posted. I just confirmed that again. Make sure you get the 1709 one. The snippet is from the EP.xml file contained in there.

This is the not a standard config in the sense that it's not automatically applied.
But Microsoft has released it as a security recommendation and there'll be plenty of admins, like me, who apply these recommendations.
It might be helpful to ask MS to remove those settings for their next release of the security baseline.
(In reply to Tobias from comment #41)
> (In reply to Jim Mathies [:jimm] from comment #40)
> 
> In this case I am that administrator. The Fall Creators' Update deprecates
> EMET and brings those new controls.
> I downloaded the "Windows 10 Version 1709 Security Baseline.zip" from the
> URL I posted. I just confirmed that again. Make sure you get the 1709 one.
> The snippet is from the EP.xml file contained in there.
> 
> This is the not a standard config in the sense that it's not automatically
> applied.
> But Microsoft has released it as a security recommendation and there'll be
> plenty of admins, like me, who apply these recommendations.
> It might be helpful to ask MS to remove those settings for their next
> release of the security baseline.

Thanks, great background. Confirmed the settings are in Microsoft's base line zip for 1709 (I had the 1703 zip initially).
Whiteboard: [AV:ESET Endpoint Antivirus, Version:5.0.2254.0 ?][AV:AVG Version:9.0.935][AV:Microsoft Defender Exploit Protection] → [AV:AVG Version:9.0.935][AV:Microsoft Defender Exploit Protection]
Hey Ritu, based on our current understanding here, this could impact users out on release at any point in the future. The triggers are:

1) New DLL filtering functionality that landed in Firefox 58
2) New off-by-default security settings available in Windows 10 1709.
3) Enterprise related defaults for GPO policy downloadable off Microsoft's site that turn these features on specifically for Firefox.

We can fix 3 by working with MS, but not 1 & 2 without some level of development. So I think we want to go ahead and ship Bob's patch which disables #1 above.

SUMO reports so far are pretty low volume so I'm not convinced a stand-alone point release is needed. I'd say, at your earliest convenience, and we'll keep an eye on SUMO reports for any change in volume.
status-firefox60: ? → fixed
Flags: needinfo?(rkothari)
https://hg.mozilla.org/mozilla-central/rev/91fb7fed2e3b
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 60
We can call GetProcessMitigationPolicy(GetCurrentProcess(), ProcessPayloadRestrictionPolicy, ...); to get the "Payload" mitigation policy and take a better action than showing blank tabs (e.g. An error message that describes the situation).
(In reply to Jim Mathies [:jimm] from comment #43)
> SUMO reports so far are pretty low volume
i wouldn't necessarily agree with that, as only a small fraction of users with a problem will make it to the support forum at all. we currently have 15 questions on sumo about this (while only a quarter of the userbase got updated to 58 so far).
as a comparison, for other major issues like bug 1418290 in 57 we got 70 or so questions in total.
Duplicate of this bug: 1432581
Moreover, with a Firefox loading a blank page, you cannot really use sumo ...
tracking-firefox58: ? → blocking
This bug does not only make some functionality unusable, but the complete browser. For that reason I'd really appreciate it, if you would deliver a bugfix release for firefox 58.
Are you using these Microsoft Defender Exploit Protection settings (comment 27)?
It would be interesting to know if the problem you're experiencing is the same or an actual conflict with AVG.
Flags: needinfo?(frfxtst)
(In reply to Bob Owen (:bobowen) from comment #50)
> Are you using these Microsoft Defender Exploit Protection settings (comment
> 27)?
> It would be interesting to know if the problem you're experiencing is the
> same or an actual conflict with AVG.

No, I don't use Defender.
Flags: needinfo?(frfxtst)
See Also: → 1418594
I've debugged this a bit.

It is this call [1] that is causing an exception further down when trying to load verifier.dll (Application Verifier).
So, this happens even in audit mode for these settings.

[1] is called from [2] in the patched version of NtMapViewOfSection, which the sandbox uses to intercept DLL loads either for patching or blocking.
So, currently it looks like turning the blocking on at all will cause this conflict with any Microsoft Defender Exploit Protection settings that require verifier.dll.

The patched version of NtMapViewOfSection is used when patching is required for DLLs that are loaded after the suspended child process is resumed by the parent, just after start-up.
We don't use this at the moment, but we will for win32k lockdown, which needs to patch things in gdi32.dll and user32.dll.
So, we need to get Microsoft to remove these settings.
(They are also there for plugin-container.exe, so this will block us from turning this on for the GMP processes.)

I notice that chrome.exe has very minimal settings in that xml file and it uses win32k lockdown.
Sure enough its child processes crash in the same way when these things are turned on.

[1] https://hg.mozilla.org/mozilla-central/file/329bfa4b804a/security/sandbox/chromium/sandbox/win/src/sandbox_nt_util.cc#l175
[2] https://hg.mozilla.org/mozilla-central/file/329bfa4b804a/security/sandbox/chromium/sandbox/win/src/target_interceptions.cc#l37
Added to 58.0 release notes as a known issue.
relnote-firefox: --- → 58+
Using AVG version 17.9.3040(free) on Windows 10 x64 not reproduced this issue on Firefox 59.0b3 and 59.0b4.
(In reply to Jim Mathies [:jimm] from comment #43)
> Hey Ritu, based on our current understanding here, this could impact users
> out on release at any point in the future. The triggers are:
> 
> 1) New DLL filtering functionality that landed in Firefox 58
> 2) New off-by-default security settings available in Windows 10 1709.
> 3) Enterprise related defaults for GPO policy downloadable off Microsoft's
> site that turn these features on specifically for Firefox.
> 
> We can fix 3 by working with MS, but not 1 & 2 without some level of
> development. So I think we want to go ahead and ship Bob's patch which
> disables #1 above.
> 
> SUMO reports so far are pretty low volume so I'm not convinced a stand-alone
> point release is needed. I'd say, at your earliest convenience, and we'll
> keep an eye on SUMO reports for any change in volume.

Thanks Jimm. Given the low risk associated with this patch and the confirmation from affected users about the problem going away with the fix from b4, there is a good chance this fix will ride 58.0.1. 

All, thanks so much for a quick resolution on this issue.
Flags: needinfo?(rkothari)
Comment on attachment 8945504 [details] [diff] [review]
Release - : Make the Chromium sandbox DLL blocking Nightly only

This is a particularly severe issue and we are hoping to include this fix in the first dot release, if possible. Release58+
Attachment #8945504 - Flags: approval-mozilla-release? → approval-mozilla-release+
Flags: needinfo?(andrei.vaida)
I have managed to reproduce the issue described in comment 0 by following the steps in comment 34 (Switching the "Stack Pivot" to "on" for firefox.exe in the windows defender exploit protection settings) while updating Firefox from 57.0.1 (BuildId:20180103231032)to Firefox 58.0 (BuildID:20180118215408) on Windows 10 64bit.

This issue is no longer reproducible using Firefox 59.0b5 (BuildId:20180128191456)and 58.0.1 (BuildId:20180128191252).

This issue seems to be reproducible using latest Firefox 60.0a1 (using the same steps as above).

Bob, can you please have a look into this? 

Thanks!
Flags: needinfo?(bobowencode)
The blocklist was set to nightly-only, so 60.0a1 being affected is pretty much expected.
Ah, I missed that. Sorry!
Flags: needinfo?(bobowencode)
Component: Untriaged → Security: Process Sandboxing
Product: Firefox → Core
Target Milestone: Firefox 60 → ---
Duplicate of this bug: 1432543
See Also: → 1447019
I have managed to reproduce the issue described in comment 0 by following the steps in comment 34 (Switching the "Stack Pivot" to "on" for firefox.exe in the windows defender exploit protection settings) on Nightly 60.0a1 (2018-01-29) on Windows 10 x64.

Verified fixed using latest Nightly 61.0a1(2018-03-26) and Beta 60.0b6.
status-firefox60: fixed → verified
Flags: qe-verify+
Firefox 60 (Windows 10) here, and this is not solved for me. I found a similar way to trigger this issue through "icacls firefox.exe /setintegritylevel low" and I experience the same issue as discussed here. icacls is a build-in windows command line tool to restrict certain applications in terms of access rights etc. And similarly, setting set MOZ_DISABLE_CONTENT_SANDBOX=1 resolves this for me. More details can be found here: https://discourse.mozilla.org/t/how-to-make-firefox-quantum-compatible-to-windows-low-integrity-level-mode-very-effectice-way-to-prevent-malware/29114

Setting low integrity level mode is a very simple but effectice way to make a web browser more secure. Internet Explorer uses this by default. And I think it should be of high interest to be at least as good as Internet Explorer in terms of support for security features ;-)
(In reply to binami from comment #71)
> Firefox 60 (Windows 10) here, and this is not solved for me. I found a
> similar way to trigger this issue through "icacls firefox.exe
> /setintegritylevel low" and I experience the same issue as discussed here.
> icacls is a build-in windows command line tool to restrict certain
> applications in terms of access rights etc. And similarly, setting set
> MOZ_DISABLE_CONTENT_SANDBOX=1 resolves this for me. More details can be
> found here:
> https://discourse.mozilla.org/t/how-to-make-firefox-quantum-compatible-to-
> windows-low-integrity-level-mode-very-effectice-way-to-prevent-malware/29114
> 
> Setting low integrity level mode is a very simple but effectice way to make
> a web browser more secure. Internet Explorer uses this by default. And I
> think it should be of high interest to be at least as good as Internet
> Explorer in terms of support for security features ;-)

Can you open a new bug?
Oh, ok. I thought that on bugzilla there is a desire to keep similar stuff together in the same bug report, but if you want a new bug report, here it is: https://bugzilla.mozilla.org/show_bug.cgi?id=1466618
See Also: → 1466618
You need to log in before you can comment on or make changes to this bug.