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 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? |
Why not just patch it out of the PE header?
|
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? |
Quote:
Quote:
Code:
Windows Registry Editor Version 5.00 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