Closed Bug 1509748 Opened 5 years ago Closed 3 years ago

[Windows 10 1809] EAF Crash

Categories

(Core :: Security, defect, P5)

Product:
Core
Component:
Security
Version:
63 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla78
Tracking Flags:
Tracking Status
firefox78 --- fixed

People

(Reporter: saydie.khalessi, Assigned: toshi)

References

Details

Crash Data

Attachments

(1 file)

Bug 1509748 - Do not touch ntdll's PE header directly if EAF+ is enabled. r=mhowell,mstange
47 bytes, text/x-phabricator-request
Details | Review 
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

1. Install Windows 10 1809
2. Under "Exploit Protection" enable "Export Address Filtering (EAF)" for firefox.exe


Actual results:

Firefox will randomly crash anywhere between 1 minute or an hour (depending on usage). In the event logs, the following gets logged under "Applications and Services Logs" -> "Microsoft" -> "Windows" -> "Security-Mitigations" -> "User Mode":

Process 'C:\Program Files\Mozilla Firefox\firefox.exe' (PID 7884) was blocked from accessing the Export Address Table for module 'C:\WINDOWS\SYSTEM32\ntdll.dll'.


Expected results:

The process should not have crashed. This has been working fine on Windows 10 1803 until the OS was updated to version 1809. Microsoft seems to have improved their EAF filtering which has broken firefox.
From the Application logs:

Faulting application name: firefox.exe, version: 63.0.3.6892, time stamp: 0x5beca9c3
Faulting module name: PayloadRestrictions.dll, version: 10.0.17763.1, time stamp: 0x7885c70a
Exception code: 0xc0000409
Fault offset: 0x000000000003b614
Faulting process id: 0x1ecc
Faulting application start time: 0x01d484fd6a12ba4e
Faulting application path: C:\Program Files\Mozilla Firefox\firefox.exe
Faulting module path: C:\WINDOWS\SYSTEM32\PayloadRestrictions.dll
Report Id: a76936ba-2041-43a5-a02a-4e27a7d35a73
Faulting package full name: 
Faulting package-relative application ID:
I'm not entirely sure on which component this issue should belong to, but as an initial triage tentative, let's triage it in Security.
Component: Untriaged → Security
Product: Firefox → Core

Has this issue been addressed? I am currently experiencing this behavior and the issue is an exact match to what was originally submitted for this bug.

I'm not sure what we would be doing that would trip a check for accessing the NTDLL EAT. The closest thing I can find is the hook that the launcher process sets up on our module's IAT for NTDLL, but that doesn't sound like what this is; it's the firefox.exe IAT that we hook, not the ntdll.dll EAT, and an issue with that would show up upon first starting the browser, not randomly. Also this bug was first reported against 63, which should not be running any of that code anyway. The only other thing of ours I can see that hooks NTDLL is the I/O interposer, but it doesn't work this way (it uses a Detours-type hooks), plus that shouldn't be running on release anyway as far as I can tell (and it also gets set up on startup).

Aaron, any ideas?

Flags: needinfo?(aklotz)

The only thing that I can think of that would do this is the Chromium sandbox - it does use EAT patching as one of the techniques for function hooking (which is obviously only useful in the case where none of the library's function pointers have been resolved yet) [1][2].

That would make sense to be coming from firefox.exe since that's where the Chromium parts live.

Flags: needinfo?(aklotz)
See Also: → 1483752

Is there an update to this one? I am also experiencing the exact same issue with ver 67, both 32bit and 64bit:

Faulting application name: firefox.exe, version: 67.0.0.7075, time stamp: 0x5cdded92
Faulting module name: PayloadRestrictions.dll, version: 10.0.17763.1, time stamp: 0x7885c70a
Exception code: 0xc0000409
Fault offset: 0x000000000003b614
Faulting process id: 0x4944
Faulting application start time: 0x01d5153082521190
Faulting application path: C:\Program Files\Mozilla Firefox\firefox.exe
Faulting module path: C:\Windows\SYSTEM32\PayloadRestrictions.dll
Report Id: dabf9a7a-73a2-4674-9970-e0c5ec49691a
Faulting package full name:
Faulting package-relative application ID:

It's unfortunate that it used to work and now does not but we don't support the EAF mitigation in Firefox. We would consider patches if anyone was interested in debugging and finding a root cause.

Priority: -- → P5

I found this bug report when searching for why my Firefox was crashing on Windows 10 1809
I'm experiencing the same crashes with the same exception code of 0xc0000409 and fault offset of 0x000000000003b614

Thanks to this thread pointing me to Export Address Filtering (EAF), I was able to find a workaround of placing that protection into Audit mode.

In case it helps others, until such time as someone can help support EAF mitigations, Here's the GUI method I used (Powershell commandlet to do the same seems to have a bug filed against it at this time)

Windows Security control panel, go to App & browser control
Scroll down to the Exploit protection section, and click on Exploit protection settings
switch from the System settings to the Program settings tab
find firefox.exe among the programs to customize, Click to expand, then click Edit
scroll down to Export address filtering (EAF)
I just switched on "Audit only" and it stopped the crashes. I expect turning it off entirely would also help.

I did have to repeat this process after Firefox auto-updated to a new version as well.

Wish I had the skills and time to help support EAF instead of just turning it off, but Firefox is useful enough to me I will continue to use it (though less often) with this protection turned off, and hope this post helps others.

This is becoming more prevalent as more and more organization is starting to use Microsoft Defender or taking advantage of the builtin security controls in Windows 10.

Would it be possible to work with Microsoft to fix this? Or has any progress been made since 4 months ago?

(In reply to spaelling from comment #9)

This is becoming more prevalent as more and more organization is starting to use Microsoft Defender or taking advantage of the builtin security controls in Windows 10.

Would it be possible to work with Microsoft to fix this? Or has any progress been made since 4 months ago?

My understanding at this time is that these crashes were occurring when EAF was turned on and third party applications were injecting into Firefox. There's not much we can do to resolve that case.

If I'm wrong though, and we can get info about a crash when no third party dlls are injected, we could at least take a look and see if there is something apparent that could be fixed.

I tested the latest Firefox build on Win 10 1809 (and 1903, too) with EAF for firefox.exe, but I didn't get a repro of 0xc0000409.

While testing, I hit a different crash of 0xc0000005 in the launcher process, so I filed Bug 1587642. Without the launcher process, I didn't observe any crash.

As Tom suggested, this crash may need more factors on top of EAF, such as third party applications or specific user operations or websites. If anybody has consistent repro steps of this crash, please let us know. I'm happy to test it on my end.

When I turned on the checkbox "Validate access for modules that are commonly abused by explots" (thank you for suggeting it, Tom), I got a crash of exception 0xc0000409 from the browser process on Win10 1903.

The crashing code was GetPdbInfo for ntdll.dll from SharedLibraryInfo::GetInfoForSelf.

0:019> r
rax=0000000000000030 rbx=00007ffc6c620000 rcx=00007ffc6c6bc524
rdx=0000000000000000 rsi=00007ffc2a605f30 rdi=0000000000000001
rip=00007ffc2903fc3e rsp=000000470e0bea70 rbp=000000470e0bee00
 r8=000000470e0bea28  r9=000000470e0bee00 r10=0000000000000000
r11=0000000000000246 r12=0003001100000000 r13=00007ffc2a60bcd2
r14=000000470e0bed68 r15=ffffffffffffffff
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
xul!SharedLibraryInfo::GetInfoForSelf+0x27e:
00007ffc`2903fc3e 0fb703          movzx   eax,word ptr [rbx] ds:00007ffc`6c620000=???? <<<< rbx is the imagebase of ntdll.dll

0:019> knL
 # Child-SP          RetAddr           Call Site
00 00000047`0e0bea70 00007ffc`291364c8 xul!SharedLibraryInfo::GetInfoForSelf+0x27e
01 00000047`0e0bf1c0 00007ffc`29136943 xul!mozilla::ReadModuleInformation+0x158
02 00000047`0e0bf5c0 00007ffc`25217184 xul!mozilla::ProcessHangStackRunnable::Run+0x13
03 00000047`0e0bf600 00007ffc`25215af5 xul!nsThread::ProcessNextEvent+0x1504
04 00000047`0e0bfba0 00007ffc`2521586e xul!NS_ProcessNextEvent+0x45
05 00000047`0e0bfbf0 00007ffc`251f3788 xul!mozilla::ipc::MessagePumpForNonMainThreads::Run+0x14e
06 00000047`0e0bfc60 00007ffc`252156e1 xul!MessageLoop::RunHandler+0x28
07 00000047`0e0bfcb0 00007ffc`25214eca xul!MessageLoop::Run+0x51
08 00000047`0e0bfd00 00007ffc`2d5e09bc xul!nsThread::ThreadFunc+0x15a
09 00000047`0e0bfd70 00007ffc`2d5ccc3a nss3!_PR_NativeRunThread+0x14c
0a 00000047`0e0bfdf0 00007ffc`695d0e72 nss3!pr_root+0xa
0b 00000047`0e0bfe20 00007ffc`6a887bd4 ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x42
0c 00000047`0e0bfe50 00007ffc`3f8790ad kernel32!BaseThreadInitThunk+0x14
0d 00000047`0e0bfe80 00007ffc`6c68ced1 mozglue!patched_BaseThreadInitThunk+0x8d
0e 00000047`0e0bfef0 00000000`00000000 ntdll!RtlUserThreadStart+0x21

From https://adsecurity.org/?p=2579 - it looks like what we're doing (from Windows perspective) is reading the export table of ntdll "from [a] specific [module] (typically used during the exploitation of memory corruption vulnerabilities)"

Chrome has had this problem too: https://seanthegeek.net/140/google-chrome-trips-emets-eaf-mitigation/

I found a couple of WONTFIX bugs that pointed to https://www.chromium.org/Home/chromium-security/chromium-and-emet which says disable EAF for Chrome and also points to this issue with some more commentary: https://bugs.chromium.org/p/chromium/issues/detail?id=643775

None of this tells me what criteria are used to decide whether a given module is 'a module typically used during the exploitation of memory corruption vulnerabilities'.

Has there been any progress on this bug? We recently upgraded to Windows 10 1809 and also migrated from Firefox ESR 60.x to 68.x and now we have this issue with our users constantly. Our organizations security policy requires EAF to be turned on for Firefox, so we need a fix to the issue.

Flags: needinfo?(wleung)

(In reply to wilsonjoseph from comment #15)

Has there been any progress on this bug? We recently upgraded to Windows 10 1809 and also migrated from Firefox ESR 60.x to 68.x and now we have this issue with our users constantly. Our organizations security policy requires EAF to be turned on for Firefox, so we need a fix to the issue.

This may not be a bug with Firefox. Microsoft removed EP from their security baseline, which I read as a subtle way to say it does not work at all as intended.

Exploit Protection

Because of reported compatibility issues with the Exploit Protection settings that we began incorporating with the Windows 10 v1709 baselines, we >have elected to remove the settings from the baseline and to provide a script for removing the settings from machines that have had those settings >applied. (See Remove-EPBaselineSettings.ps1 in the download package’s Scripts folder.)

source: Security baseline (FINAL) for Windows 10 v1909 and Windows Server v1909

Thanks for the reply. We didn't have the crashing issue on 1809 with Firefox ESR 60.x so that is why we were tracking it was a Firefox issue.

Flags: needinfo?(wleung)

At Firefox 71 and latest Windows 10 update this is still happening and more often than before. Removed all the extensions that I had installed and it didn't resolve the issue.

(In reply to Adam Johnson from comment #8)

Windows Security control panel, go to App & browser control
Scroll down to the Exploit protection section, and click on Exploit protection settings
switch from the System settings to the Program settings tab
find firefox.exe among the programs to customize, Click to expand, then click Edit
scroll down to Export address filtering (EAF)
I just switched on "Audit only" and it stopped the crashes. I expect turning it off entirely would also help.

My win10 system doesn't have an entry here for Firefox and I'm running 1903. Sl we need to understand how this entry ended up here. Can you post your about:support?

(In reply to spaelling from comment #16)

(In reply to wilsonjoseph from comment #15)

Has there been any progress on this bug? We recently upgraded to Windows 10 1809 and also migrated from Firefox ESR 60.x to 68.x and now we have this issue with our users constantly. Our organizations security policy requires EAF to be turned on for Firefox, so we need a fix to the issue.

This may not be a bug with Firefox. Microsoft removed EP from their security baseline, which I read as a subtle way to say it does not work at all as intended.

Exploit Protection

Because of reported compatibility issues with the Exploit Protection settings that we began incorporating with the Windows 10 v1709 baselines, we >have elected to remove the settings from the baseline and to provide a script for removing the settings from machines that have had those settings >applied. (See Remove-EPBaselineSettings.ps1 in the download package’s Scripts folder.)

source: Security baseline (FINAL) for Windows 10 v1909 and Windows Server v1909

Ah, I see so they backed this off.

Crash Signature: [@ LdrpSnapModule]

I don't think this signature is correct. I had thought these crashes were failing in a way that breakpad didn't catch, and they were going to Windows Error Reporting.

I'm affected by this, too. I initially filed a report here: https://support.mozilla.org/en-US/questions/1287256#answer-1313902

The Windows Event Viewer gives me this message upon a crash:

Faulting application name: firefox.exe, version: 76.0.1.7432, time stamp: 0x5eb403e6 Faulting module name: PayloadRestrictions.dll, version: 10.0.17763.1, time stamp: 0x7885c70a Exception code: 0xc0000409 Fault offset: 0x000000000003b614 Faulting process id: 0x1bf8 Faulting application start time: 0x01d62da298efe57c Faulting application path: C:\Program Files\Mozilla Firefox\firefox.exe Faulting module path: C:\WINDOWS\SYSTEM32\PayloadRestrictions.dll Report Id: 5ce6761f-90af-4006-a3aa-66f6b47c290d Faulting package full name: Faulting package-relative application ID:

Does this here
(In reply to spaelling from comment #16)

(In reply to wilsonjoseph from comment #15)

Has there been any progress on this bug? We recently upgraded to Windows 10 1809 and also migrated from Firefox ESR 60.x to 68.x and now we have this issue with our users constantly. Our organizations security policy requires EAF to be turned on for Firefox, so we need a fix to the issue.

This may not be a bug with Firefox. Microsoft removed EP from their security baseline, which I read as a subtle way to say it does not work at all as intended.

Exploit Protection

Because of reported compatibility issues with the Exploit Protection settings that we began incorporating with the Windows 10 v1709 baselines, we >have elected to remove the settings from the baseline and to provide a script for removing the settings from machines that have had those settings >applied. (See Remove-EPBaselineSettings.ps1 in the download package’s Scripts folder.)

source: Security baseline (FINAL) for Windows 10 v1909 and Windows Server v1909

Mean that the issue won't occur anymore with Windows 1909 because of changes to EAF?

I'm also affected by this. OS is Windows 10 Version 1809 - Build 17763.1158.
Firefox crashes at startup, no crash log is written.

The syslog event shows the following:
Protokollname: Application Quelle: Application Error Datum: 18.05.2020 18:17:38 Ereignis-ID: 1000 Aufgabenkategorie:(100) Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Beschreibung: Name der fehlerhaften Anwendung: firefox.exe, Version: 76.0.1.7432, Zeitstempel: 0x5eb403e6 Name des fehlerhaften Moduls: PayloadRestrictions.dll, Version: 10.0.17763.1, Zeitstempel: 0x7885c70a Ausnahmecode: 0xc0000409 Fehleroffset: 0x000000000003b614 ID des fehlerhaften Prozesses: 0x2dac Startzeit der fehlerhaften Anwendung: 0x01d62d2cfe11a745 Pfad der fehlerhaften Anwendung: C:\Program Files\Mozilla Firefox\firefox.exe Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\PayloadRestrictions.dll Berichtskennung: b526907a-29e2-4ad0-8509-b63543a4bddc
Please fix this!!

Mean that the issue won't occur anymore with Windows 1909 because of changes to EAF?

No, it fundamentally can't work, and because of that Microsoft removed it (EAF) from their recommendations. If you have it enabled, you should disabled it. If it's a corporate IT policy, point them to the quoted section from the security baseline in comment 16, which explains exactly this and how to remove the setting.

I think we misread Microsoft's statement. First of all, EAF setting still exists in Win10 1909. When they say we have elected to remove the settings from the baseline, they meant that the new baseline disabled EAF for the specific executables the previous baseline had enabled.

Looking at their baseline package (especially Scripts/ConfigFiles/EP-reset.xml in it), the script disables EAF for MS Office, Adobe Reader, Java, and a few more. For firefox.exe (and chrome.exe), however, it disables only DEP, but no change on EAF.

(In reply to webersebastian from comment #25)

I'm also affected by this. OS is Windows 10 Version 1809 - Build 17763.1158.
Firefox crashes at startup, no crash log is written.

I think you have enabled EAF for firefox.exe in Windows defender's Exploit protection setting. Unfortunately Firefox does not support EAF
becase we need to access Export Table for our feature. Can you turn off EAF for firefox.exe?

Alas, turning EAF off requires super admin privileges, which I do not have because I'm using a company managed laptop.
I have local admin rights but these are unfortunately not enough.

What is going to happen with this bug? Is there at least a workaround for non super admin? Checking with mozregression, I found out that the first build not working is 2018-07-10. 2018-07-09 works ok.
Is it possible to roll back the changes done on 2018-07-09?

What is going to happen with this bug? Is there at least a workaround for non super admin? Checking with mozregression, I found out that the first build not working is 2018-07-10. 2018-07-09 works ok.

Good question. I'm not an expert on this, but my guess would be that it was probably this change: https://bugzilla.mozilla.org/show_bug.cgi?id=1460022 Unfortunately, that change itself doesn't seem to do anything that should trigger EAF, it's mostly moving code around! That matches the exasperation of the Chome developers here: https://www.chromium.org/Home/chromium-security/chromium-and-emet and especially here: https://bugs.chromium.org/p/chromium/issues/detail?id=643775#c25 that essentially unrelated optimization changes trigger EAF. So even if we somehow found out what triggers the EAF (it's not documented...), there's no guarantee we can prevent it or they wouldn't randomly reoccur.

Even worse, even if we managed to somehow work around it temporarily, the process mitigation DisallowWin32kSystemCalls (a very high impact security feature we want to ship this year) requires EAT modification: https://searchfox.org/mozilla-central/rev/b59a99943de4dd314bae4e44ab43ce7687ccbbec/security/sandbox/chromium/sandbox/win/src/process_mitigations_win32k_dispatcher.cc#126

So it all really boils down to: EAF should be disabled.

What can we do here? Talk to MS and see if they want to change (https://bugzilla.mozilla.org/show_bug.cgi?id=1509748#c27) and get sysadmins to rerun/update it? Write a SUMO (support.mozilla.org) article detailing how EMET/EAF hurts security and should be disabled, that we can point sysadmins to?

(In reply to Gian-Carlo Pascutto [:gcp] from comment #30)

What can we do here? Talk to MS and see if they want to change (https://bugzilla.mozilla.org/show_bug.cgi?id=1509748#c27) and get sysadmins to rerun/update it? Write a SUMO (support.mozilla.org) article detailing how EMET/EAF hurts security and should be disabled, that we can point sysadmins to?

I posted a new thread in the Security Baselines discussion forum. If they agree and the baseline is updated, our statement will become more clear.

I did a quick research to see the possibility not to touch an EAF-protected area. Good news is there are only two places we need to change. If those are skipped, Firefox starts normally with EAF! It was a lot easier than I expected. One is the code to cache ntdll's functions (bug 1630281) which I recently introduced to address the interop issue. The other one is the profiler code mentioned in comment #13.

Let me prepare a patch. Once it's ready, I'll share a private version here for testing before landing.

Please note that even if we could fix EAF crash for now, it's possible that a future change might introduce another EAF crash.

A private version of Firefox is ready for testing.

@webersebastian, can you download and try it on your environment? No installation is needed. Please download target.zip from the following link, unpack it, and run firefox.exe in it.

target.zip (for 64bit) :
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/FdH54rRRQrC808xq0t1VSQ/runs/0/artifacts/public/build/target.zip
(and The submitted job)

I did sanity check on Win10 1909 with EAF+, and no problem was observed. I want to make sure this works on your end as well before proceeding.

Flags: needinfo?(webersebastian)

(In reply to Toshihito Kikuchi [:toshi] from comment #33)

A private version of Firefox is ready for testing.

@webersebastian, can you download and try it on your environment? No installation is needed. Please download target.zip from the following link, unpack it, and run firefox.exe in it.

target.zip (for 64bit) :
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/FdH54rRRQrC808xq0t1VSQ/runs/0/artifacts/public/build/target.zip
(and The submitted job)

I did sanity check on Win10 1909 with EAF+, and no problem was observed. I want to make sure this works on your end as well before proceeding.

This version seems to work perfectly! It is running now for 30 Minutes and no crash :-)

Flags: needinfo?(webersebastian)

(In reply to Toshihito Kikuchi [:toshi] from comment #33)

A private version of Firefox is ready for testing.

@webersebastian, can you download and try it on your environment? No installation is needed. Please download target.zip from the following link, unpack it, and run firefox.exe in it.

target.zip (for 64bit) :
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/FdH54rRRQrC808xq0t1VSQ/runs/0/artifacts/public/build/target.zip
(and The submitted job)

I did sanity check on Win10 1909 with EAF+, and no problem was observed. I want to make sure this works on your end as well before proceeding.

I'm giving it a run as well, and so far, it seems to be working well. I've seen no crashes of any sort.

However, Firefox Sync isn't snychronizing my bookmarks - is that normal when testing a nightly build, to prevent data corruption?

@webersebastian and @thomas.wahrlich, thank you for testing the private version! That's a great news that it worked well without any problem! Let us proceed to ship this fix.

(In reply to thomas.wahrlich from comment #35)

However, Firefox Sync isn't snychronizing my bookmarks - is that normal when testing a nightly build, to prevent data corruption?

It's expected because you unpacked target.zip instead of upgrading the existing Firefox profile.

(In reply to Toshihito Kikuchi [:toshi] from comment #36)

@webersebastian and @thomas.wahrlich, thank you for testing the private version! That's a great news that it worked well without any problem! Let us proceed to ship this fix.

(In reply to thomas.wahrlich from comment #35)

However, Firefox Sync isn't snychronizing my bookmarks - is that normal when testing a nightly build, to prevent data corruption?

It's expected because you unpacked target.zip instead of upgrading the existing Firefox profile.

Understood, however, I logged in to my Firefox profile using the nightly, and I still don't see any snychronization.

(In reply to thomas.wahrlich from comment #37)

Understood, however, I logged in to my Firefox profile using the nightly, and I still don't see any snychronization.

Hmm, that's strange. My patch does not change anything in the synchronization part. The private version is based on the development branch, which may include an imperfect commit. If you see the same issue in the official Nightly build, please file a new bug.

If EAF+ is enabled for firefox.exe, the process does not launch because we parse
the PE headers of ntdll.dll which is prohibited by EAF+.
With this patch, we skip two operations if EAF+ is enabled, caching ntdll's IAT
at startup and retrieving ntdll's PDB info for the base profiler.

Assignee: nobody → tkikuchi

PDB information is needed by the profiler in order to be able to tell which pc values (instruction addresses) belong to which library, and how to translate those addresses to symbols. In particular, the profiler needs to know, for each loaded library, which range in memory a library covers, what the library's dll and pdb name are, and what its pdbSignature and pdbAge are. This allows it to translate absolute addresses into library-relative addresses, and to find the correct symbol table based on the library's name and signature. If the profiler does not have this information, it cannot find symbol information, and the profiler will show raw addresses rather than function names for all functions that were observed in this library.
Does this only affect ntdll? Which type of Firefox process does it affect? All processes, or just certain subprocesses such as the network process?

Here's an example profile, filtered to "ntdll", with inverted call stacks: https://share.firefox.dev/3d59N2h
You can see many function names from ntdll, e.g. NtWaitForAlertByThreadId, NtAllocateVirtualMemory, RtlEnterCriticalSection.
Not having those function names would make Windows profiles substantially harder to read.

Right now, on machines with EAF turned on, no profiles are generated at all - Firefox crashes at startup. If I understood right, the parsing of PE headers is only skipped if EAF is turned on. This means, on the majority of machines, profiles will still have function names included. This patch improves the situation that no profiles are generated at all on machines with EAF turned on.
Please fix this bug quickly - right now, I am stuck with Edge (which sucks!)

That is a very convincing argument. Nevertheless, it would be good to come up with a plan to obtain this information even when EAF is turned on.

Thanks for your comments! As @webersebastian mentioned, if EAF+ is enabled for firefox.exe, Firefox does not launch at all even though a user does not user the profiler. Given that the side effect, the name of ntdll's functions are not shown in the profiler, is not very critical to browsing experience, it's important to unblock users with EAF+.

(In reply to Markus Stange [:mstange] from comment #40)

Does this only affect ntdll? Which type of Firefox process does it affect? All processes, or just certain subprocesses such as the network process?

EAF/EAF+ is enabled for the program name, firefox.exe. So it affects all of our processes.

Microsoft does not publish the detailed behavior of EAF+ or the list of EAF-protected modules. Currently skipping ntdll.dll is enough, but it's not guaranteed in the future. That's why enabling EAF/EAF+ for firefox.exe is still not recommended.

Fyi, the following article explains the difference between EAF and EAF+.

Announcing EMET 5.0 - Microsoft Security Response Center
https://msrc-blog.microsoft.com/2014/07/31/announcing-emet-5-0/

(In reply to Markus Stange [:mstange] from comment #43)

That is a very convincing argument. Nevertheless, it would be good to come up with a plan to obtain this information even when EAF is turned on.

Can we get it from a local file using CreateFile and ReadFile?

Attachment #9151933 - Attachment description: Bug 1509748 - Do not touch ntdll's PE header directly if EAF+ is enabled. r=mhowell → Bug 1509748 - Do not touch ntdll's PE header directly if EAF+ is enabled. r=mhowell,mstange
Pushed by rmaries@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/34c3a4a251e8
Do not touch ntdll's PE header directly if EAF+ is enabled.  r=mhowell,mstange

https://hg.mozilla.org/mozilla-central/rev/34c3a4a251e8

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
status-firefox78: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla78

We published the following page about compatibility with EAF/EAF+ and other Windows mitigations. You can point to this page when you let IT admins know about our recommendation.

Compatibility with Exploit protection in Windows 10 | Firefox Help
https://support.mozilla.org/en-US/kb/compatibility-exploit-protection-windows-10

If you hit a new problem with EAF or other migations, please file a new bug. We cannot guarantee full compatibility, but we're happy to investigate it and find out what we can do!

See Also: → 1746932
Duplicate of this bug: 1824964
You need to log in before you can comment on or make changes to this bug.