even assuming that your special process is perfectly protected during initialization, all UM VA includes data that does not exactly match the disk image - and it is infeasible to ‘protect’ all of the loaded DLLs and relocation information. So yes, I can hijack your special process in UM after you have verified the image. And I can do it not just on my machine with a debugger hooked up, but on any other machine that has my software installed.
The short version is to use the security model implemented by the OS
I’m still arguing for a solution that I will not end up using just to learn what is wrong with it.
I fake you out into thinking that my process is your “special process”
Good luck finding a preimage for my signed sections.
UM VA includes data that does not exactly match the disk image
This doesn’t apply to all sections. Specifically, the .text section is mapped as is. I know you could probably find a way around it by adding sections etc. but I wonder if the Windows security model (without the PPL which costs money) prevents all the mentioned attacks!
Note that a Windows solution for this is having a PPL. It attacks the problem a little differently by ensuring you can create a service that only runs code signed by you or Microsoft. Combine that with a Service SID and you’re pretty hardened.
services can’t start with arbitrary names. Services can only start with names that have been preconfigured in the registry and the parameters passed to StartServiceCtrlDispatcher must match with those that the SCM expects when it launched the process or send a control to a shared process service. The SIDs derive from the names because they must be unique and must be installed by an admin
If I have access to your software, and a debugger, I will surely be able to find a match to your ‘super special’ section in minutes - a few hours at the most. At worst, I just use your whole image, but the start execution somewhere else that never calls your code. you can’t protect against that kind of attack without also making your software unusable after a Windows update
The SCM has to start every service process in the context of some security principal. When users start ordinary processes using the start menu or shortcuts, those processes inherit the security principal of the process that launches them - usually explorer.exe running as the the logged in user.
but the SCM runs as LOCAL SYSTEM, but not every service should. When it must run a service that should run under a different security principal, it must login as that principal in order to generate a token that can then be used by that process to arbitrate its access to various resources. For some accounts, it can use its TCB Name (act as part of the operating system) privileges, but for others it must rely on a saved password