Exetools  

Go Back   Exetools > General > General Discussion

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 08-05-2021, 04:11
DavidXanatos DavidXanatos is offline
Family
 
Join Date: Jun 2018
Posts: 128
Rept. Given: 1
Rept. Rcvd 31 Times in 21 Posts
Thanks Given: 42
Thanks Rcvd at 270 Times in 85 Posts
DavidXanatos Reputation: 31
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?
Reply With Quote
The Following User Says Thank You to DavidXanatos For This Useful Post:
niculaita (08-05-2021)
  #2  
Old 08-05-2021, 05:11
deepzero's Avatar
deepzero deepzero is offline
VIP
 
Join Date: Mar 2010
Location: Germany
Posts: 284
Rept. Given: 104
Rept. Rcvd 63 Times in 41 Posts
Thanks Given: 134
Thanks Rcvd at 178 Times in 84 Posts
deepzero Reputation: 63
Why not just patch it out of the PE header?
Reply With Quote
  #3  
Old 08-05-2021, 05:28
deepzero's Avatar
deepzero deepzero is offline
VIP
 
Join Date: Mar 2010
Location: Germany
Posts: 284
Rept. Given: 104
Rept. Rcvd 63 Times in 41 Posts
Thanks Given: 134
Thanks Rcvd at 178 Times in 84 Posts
deepzero Reputation: 63
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?
Reply With Quote
The Following User Says Thank You to deepzero For This Useful Post:
DavidXanatos (08-05-2021)
  #4  
Old 08-05-2021, 14:58
DavidXanatos DavidXanatos is offline
Family
 
Join Date: Jun 2018
Posts: 128
Rept. Given: 1
Rept. Rcvd 31 Times in 21 Posts
Thanks Given: 42
Thanks Rcvd at 270 Times in 85 Posts
DavidXanatos Reputation: 31
Quote:
Originally Posted by deepzero View Post
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...
Reply With Quote
The Following User Says Thank You to DavidXanatos For This Useful Post:
niculaita (08-06-2021)
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT +8. The time now is 18:45.


Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX
( 1998 - 2021 )