Exetools

Exetools (https://forum.exetools.com/index.php)
-   General Discussion (https://forum.exetools.com/forumdisplay.php?f=2)
-   -   Disabling Hardware-enforced Stack Protection (https://forum.exetools.com/showthread.php?t=19899)

DavidXanatos 08-05-2021 04:11

Disabling Hardware-enforced Stack Protection
 
Some application nowadays have the compiler flag set to use Hardware-enforced Stack Protection from the get go.
That shows to be problematic with some code injection strategies, for example like done by sandboxie...

So I wonder how to best disable this for starting processes...

I have looked a bit into the kernel and how these flags are set,
it seams the NtCreateUserProcess is setting a dword at EPROCESS + 0x09D4
which indicates if these mitigation are in place,
I found these offset by looking at NtSetInformationProcess so there may be additional flags I'm not aware of...
I deduce that NtCreateUserProcess sets them as it reads the "MitigationOptions" from "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\TestApp.exe" where TestApp.exe is the name of the process being created.


I have tried to set EPROCESS + 0x09D4 to 0 during a callback registered with PsSetCreateProcessNotifyRoutineEx
but this did not work, logging registry accesses to the "Image File Execution Options" key and the creation callback it looks this:

Code:

key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  UseFilter
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  LoadCHPEBinaries????????
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  UseFilter
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  Debugger
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  UseLargePages
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  NodeOptions
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  ForceWakeCharge
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  AllowedCpuSets
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  MitigationOptions
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  MitigationAuditOptions
Process_NotifyProcessEx pid=1564 parent=6320 current=6320 created=y notepad.exe flag: 00000000
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  UseFilter
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  DisableHeapLookaside????
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  FrontEndHeapDebugOptions
key access: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe  ->  ShutdownFlagsebugOptions

So apparently the MitigationOptions are read and applied before the callback what is really a problem, when i would want to decide in PsSetCreateProcessNotifyRoutineEx if the process should be sandboxed or not and prepare teh right registry entry to avoid this mitigation being enabled.....
And resetting the flag as mentioned did not have the desired effect, probably there is a second flag or something that would need tempering with as well,
or possibly its not even possible to disable it at this stage as the shadow stack and variouse other things are already configured for that initial thread...
Not cool not cool at all...



Anyhow I was wondering if anyone here would have an idea how to elegantly exclude processes from having this mitigation applied, or how to properly disable this mitigation from the kernel?

deepzero 08-05-2021 05:11

Why not just patch it out of the PE header?

deepzero 08-05-2021 05:28

https://i.blackhat.com/asia-19/Thu-March-28/bh-asia-Sun-How-to-Survive-the-Hardware-Assisted-Control-Flow-Integrity-Enforcement.pdf

says master enable: CR4.CET (bit 23)
process specific details on p28ff... MitigationFlags2...

why do you think it can be disabled via registry?

DavidXanatos 08-05-2021 14:58

Quote:

Originally Posted by deepzero (Post 123535)
Why not just patch it out of the PE header?

Well snadboxie is not supposed to alter the unsandboxed files thats why, as a worst case workaround though I could always make a sandboxed copy of a file with the patch applied but that's not really what i want.


Quote:

why do you think it can be disabled via registry?
because I can:

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\chrome.exe]
"MitigationOptions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,20,00,00,\
  00,00,00,00,00,00
"MitigationAuditOptions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00
"EAFModules"=""

Thats what the deffender UI does when I disable it there for a given process here chrome.exe and i tested when i add such entries with reg edit they also are im effect.

as said it seams that NtCreateUserProcess is reading this location and applying the values as instructed.

So when spawning processes from within the sandbox, where I have a hook at CreateProcessInternalW I can use the unsandboxed helper service to create the required reg entries.


The only scenario that is thoroughly broken is the forces process feature, of sandboxie, where a user starts a process outside by whatever means and this process based on its name, working directory or so is to be forced into the sandbox. A worst case workaround would be to kill it when sbie notices that flag is set and re spawn it in the sandbox. Not the best of all possible solutions but if nothing else works also a viable option in the end.




Anyhow I have looked mor thoroughly into what is actually broken with all the sandboxie hooks and etc ... and it seams the low level injection mechanism is fine as well as the later sbiedll hooks, the only thing that gets broken by this mitigation are the hooks on all the ntdll syscall stubs so possibly there is a way to re architecture those hooks in a way that will work with that mitigation...


All times are GMT +8. The time now is 14:10.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX