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

Status: VERIFIED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

[Tobias]

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).

Comment 1

[Tobias]

Disabling the content sandbox using "set MOZ_DISABLE_CONTENT_SANDBOX=1" stops the problem from appearing.

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Seems like a pretty critical issue.
Jim, Bob, does it ring a bell?

Comment 3

[Marco Castelluccio [:marco]]

Tobias, what antivirus do you have on your machine?

Comment 4

[Tobias]

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

Comment 5

[testit]

I'm using AVG antivirus and experience the same problem.

Comment 6

[Bob Owen (:bobowen)]

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.

Comment 7

[Bob Owen (:bobowen)]

Attachment: Make the Chromium sandbox DLL blocking Nightly only

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/541ea4baacba
Make the Chromium sandbox DLL blocking Nightly only. r=jimm

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Bob, could you please fill the uplift request so that we are ready in case/when we want to take the patch

Comment 10

[Bob Owen (:bobowen)]

(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. :-(

Comment 11

[Pulsebot]

Pushed by [e-mail]:
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 12

[Bob Owen (:bobowen)]

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

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 14

[Bob Owen (:bobowen)]

Attachment: Release - : Make the Chromium sandbox DLL blocking Nightly only

Comment 15

[Bob Owen (:bobowen)]

Comment on attachment 8945504 [details] [diff] [review]
Release - : Make the Chromium sandbox DLL blocking Nightly only

See comment 12.

Comment 16

[(PTO June 19-July 7) Ryan VanderMeulen]

https://hg.mozilla.org/releases/mozilla-beta/rev/783507b1b80d

Comment 17

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8945504 [details] [diff] [review]
Release - : Make the Chromium sandbox DLL blocking Nightly only

We want that in release too.

Comment 18

[Sylvestre Ledru [:Sylvestre]]

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.

Comment 19

[testit]

(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.

Comment 20

[Jim Mathies [:jimm]]

testit, what version of AVG are you using?

Comment 21

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 22

[testit]

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.

Comment 23

[Jim Mathies [:jimm]]

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?

Comment 24

[Jim Mathies [:jimm]]

(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!

Comment 25

[Tobias]

(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.

Comment 26

[Bob Owen (:bobowen)]

(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

Comment 27

[Tobias]

(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.

Comment 28

[testit]

(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.

Comment 29

[[:philipp]]

> (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...

Comment 30

[Jim Mathies [:jimm]]

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.

Comment 31

[testit]

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.

Comment 32

[Bob Owen (:bobowen)]

(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.

Comment 33

[Tobias]

(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>

Comment 34

[[:philipp]]

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.

Comment 35

[[:philipp]]

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

Comment 36

[Tobias]

(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.

Comment 37

[Bob Owen (:bobowen)]

(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.

Comment 38

[Tobias]

(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

Comment 39

[[:philipp]]

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

Comment 40

[Jim Mathies [:jimm]]

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.

Comment 41

[Tobias]

(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.

Comment 42

[Jim Mathies [:jimm]]

(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).

Comment 43

[Jim Mathies [:jimm]]

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.

Comment 44

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/91fb7fed2e3b

Comment 45

[Masatoshi Kimura [:emk]]

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).

Comment 46

[[:philipp]]

(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.

Comment 48

[Sylvestre Ledru [:Sylvestre]]

Moreover, with a Firefox loading a blank page, you cannot really use sumo ...

Comment 49

[testit]

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.

Comment 50

[Bob Owen (:bobowen)]

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.

Comment 51

[testit]

(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.

Comment 52

[Bob Owen (:bobowen)]

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

Comment 53

[Julien Cristau [:jcristau]]

Added to 58.0 release notes as a known issue.

Comment 54

[Timea Zsoldos [:tzsoldos], Desktop QA]

Using AVG version 17.9.3040(free) on Windows 10 x64 not reproduced this issue on Firefox 59.0b3 and 59.0b4.

Comment 55

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(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.

Comment 56

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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+

Comment 57

[(PTO June 19-July 7) Ryan VanderMeulen]

https://hg.mozilla.org/releases/mozilla-release/rev/331ee7992955

Comment 58

[goonatic66]

Apologies for potentially hijacking this thread, but I've seen identical issues since upgrading to v58 on a Win10 Pro x64 system with the latest install of Kaspersky (and Malwarebytes, if that makes any difference). Are steps being taken to address this bug under Kaspersky as well? Thanks.

Comment 59

[Bob Owen (:bobowen)]

(In reply to goonatic66 from comment #58)
> Apologies for potentially hijacking this thread, but I've seen identical
> issues since upgrading to v58 on a Win10 Pro x64 system with the latest
> install of Kaspersky (and Malwarebytes, if that makes any difference). Are
> steps being taken to address this bug under Kaspersky as well? Thanks.

Sounds like bug 1418594, which will hopefully have been fixed as well.
If it is the same problem, then you could try the instructions in comment 26 to test the latest Beta.
If the problem isn't fixed there and you think it is different from bug 1418594, please file another bug, thanks.

Comment 60

[goonatic66]

I think this is different. This is not down to Malwarebytes closing a website down (I get a pop-up if it blocks one). What I get is this...

"Your connection is not secure

The owner of www.facebook.com has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website.

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox may only connect to it securely. As a result, it is not possible to add an exception for this certificate."

I get this on every site I go to since upgrading to v58 and 59b4 didn't make any difference at all.

Comment 61

[[:philipp]]

yes, this is a different matter - please configure kaspersky like it's described at https://support.mozilla.org/en-US/kb/troubleshoot-SEC_ERROR_UNKNOWN_ISSUER

Comment 62

[goonatic66]

Yes, I saw that one, but in my book that's not a fix, it's fatally compromising the security of my online existence to work around something introduced by Firefox. I was trying to find out if there was a real fix so I wouldn't have to bin FF and reluctantly revert to IE/Edge.

Comment 63

[[:philipp]]

update your kaspersky software to the 2018 version or else reinstall it. if that doesn't help, open a question at https://support.mozilla.org/ which is a better place to troubleshoot an issue than here in an unrelated bug report.

Comment 64

[goonatic66]

Thanks. Already running 2018 and reinstalled FF, Kaspersky and Malwarebytes to no effect. Will do. Apologies. New to all this & clutching at straws.

Comment 65

[Emil Ghitta, QA [:emilghitta]]

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!

Comment 66

[Julien Cristau [:jcristau]]

The blocklist was set to nightly-only, so 60.0a1 being affected is pretty much expected.

Comment 67

[Emil Ghitta, QA [:emilghitta]]

Ah, I missed that. Sorry!

Comment 69

[roxleitan]

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.

Comment 70

[info]

Guys, are you joking ? Since 58 i cant use Firefox anymore ! it just doesn't load pages. 
I had to roll back to earlier version , which kept showing me stupid banner to update FF every 5 minutes  (Who the f... made this banner ?! - if i have disabled updates - i dont wanna see it!) .

Anyway i though verison 60 would solve the issue - but no ... http://i66.tinypic.com/2i9m2jt.jpg

I mean - you're just killing the beloved browser with your unprofessional "improvments" ... 

PS - if you f..ed it up - at least make a proper thread which fast fix or smth, as all i can find as a soluiton is "clear the cache"... 

PPS - same profile Developer Edition of Firefox works fine...

Comment 71

[binami]

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 ;-)

Comment 72

[Marco Castelluccio [:marco]]

(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?

Comment 73

[binami]

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