[FAQ] Why ReHIPS was developed or a story of broken runas

Started by fixer, June 01, 2017, 12:53:13 PM

Previous topic - Next topic

fixer

I know, some people say like "so ReHIPS executes process from some other restricted user, so why do we need it, we have runas for the same job". You're right... mostly, with one correction: you HAD runas. There were times of Windows XP when runas was pretty safe to use for processes isolation, you just create a restricted user and use runas to execute an untrusted process from it. And this process ran pretty isolated. But all good things eventually come to an end and this one is no exception. Vista introduced UAC and broken runas. No, it still executes process from some other user, but doesn't isolate anymore. For example, SetWindowsHookEx works just fine injecting DLL into other users' processes on the same desktop and that leads to arbitrary code execution. It reverts to previous XP-style security model if you disable UAC. But hey, who does that? And it's not a bug, it's a feature as desktop is not a security boundary, so noone is going to fix it, runas is not suitable for isolating processes anymore.

And out of 3 documented API functions to execute processes from another user: CreateProcessWithLogonW, CreateProcessAsUser and CreateProcessWithTokenW only 1 is suitable - CreateProcessWithTokenW. CreateProcessWithLogonW doesn't support token at all and CreateProcessAsUser creates with the same LogonSid which leads to the same runas security problems. And MSDN isn't quite correct about that only remaining function:
QuoteThe process is run in the session specified in the token. By default, this is the same session that called LogonUser. To change the session, use the SetTokenInformation function.
Actually it won't help, this function creates processes ONLY in current session.

So CreateProcessWithTokenW function and ReHIPS are the only way to isolate processes in a secure and reliable way.