[Windows 10 1809] EAF Crash
Categories
(Core :: Security, defect, P5)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox78 | --- | fixed |
People
(Reporter: saydie.khalessi, Assigned: toshi)
References
Details
Crash Data
Attachments
(1 file)
|
Reporter | |
Comment 1•6 years ago
|
||
|
||
Comment 2•6 years ago
|
||
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.
|
||
Comment 4•6 years ago
|
||
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?
|
||
Comment 5•6 years ago
•
|
||
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.
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:
|
||
Comment 7•6 years ago
|
||
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.
|
||
Comment 8•6 years ago
|
||
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?
|
|
||
Comment 10•6 years 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.
| Comment hidden (advocacy) |
|
Assignee | |
Comment 12•6 years ago
|
||
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.
|
|
Assignee | |
Comment 13•6 years ago
|
||
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
|
|
||
Comment 14•6 years ago
|
||
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'.
|
||
Comment 15•5 years ago
|
||
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.
|
||
Comment 16•5 years ago
|
||
(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
|
|
||
Comment 17•5 years ago
|
||
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.
|
||
Comment 18•5 years ago
|
||
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.
|
||
Comment 19•5 years ago
|
||
(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?
|
|
||
Comment 20•5 years ago
|
||
(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.
|
||
Updated•5 years ago
|
|
|
||
Comment 22•5 years ago
|
||
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.
|
||
Comment 24•5 years ago
|
||
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?
|
||
Comment 25•5 years ago
|
||
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!!
|
||
Comment 26•5 years ago
•
|
||
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.
|
|
Assignee | |
Comment 27•5 years ago
|
||
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?
|
|
||
Comment 28•5 years ago
|
||
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.
|
|
||
Comment 29•5 years ago
|
||
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?
|
|
||
Comment 30•5 years ago
|
||
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?
|
|
Assignee | |
Comment 31•5 years ago
|
||
(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.
|
|
Assignee | |
Comment 32•5 years ago
|
||
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.
|
|
Assignee | |
Comment 33•5 years ago
|
||
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.
|
|
||
Comment 34•5 years ago
|
||
(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 :-)
|
|
||
Comment 35•5 years ago
|
||
(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?
|
|
Assignee | |
Comment 36•5 years ago
|
||
@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.
|
|
||
Comment 37•5 years ago
|
||
(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.
|
|
Assignee | |
Comment 38•5 years ago
|
||
(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.
|
|
Assignee | |
Comment 39•5 years ago
|
||
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.
|
||
Updated•5 years ago
|
|
||
Comment 40•5 years ago
|
||
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?
|
|
||
Comment 41•5 years ago
|
||
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.
|
|
||
Comment 42•5 years ago
|
||
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!)
|
|
||
Comment 43•5 years ago
|
||
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.
|
|
Assignee | |
Comment 44•5 years ago
|
||
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/
|
|
Assignee | |
Comment 45•5 years ago
|
||
(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?
|
|
||
Updated•5 years ago
|
|
||
Comment 46•5 years ago
|
||
|
||
Comment 47•5 years ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 49•5 years ago
|
||
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!
Description
•