Comments on: Quickpost: SelectMyParent or Playing With the Windows Process Tree

By: Didier Stevens

Didier Stevens — Thu, 03 Dec 2009 21:50:06 +0000

@Skywing Thanks for the clarification. And I agree there is no security issue.

By: Skywing

Skywing — Thu, 03 Dec 2009 21:45:45 +0000

Yes, that’s correct. Someone could have just as easily thunked down to the raw system call however and bypassed CreateProcess, so this is something that has required handling from the get-go and not just on Vista or later. It’s entirely possible to do exactly the same thing on earlier systems, and

Note that there is no security implication here as privileged access (PROCESS_CREATE_PROCESS) to a process is required to inherit from it. This access right is typically only given to the object owner, system, and administrators.

By: Didier Stevens

Didier Stevens — Thu, 03 Dec 2009 19:22:50 +0000

@Skywing

Interesting. So the NtCreateProcess* functions exported by ntdll.dll have always allowed this, but it’s only starting with Vista that CreateProcess exported from kernel32.dll also allows this?

By: Skywing

Skywing — Thu, 03 Dec 2009 19:11:13 +0000

This has always been the case on NT, actually. The underlying system call has always allowed you to specify an inherit from process handle (provided you have PROCESS_CREATE_PROCESS access to said processs — a sensitive access level).

It just so happens that the Win32 wrapper typically always uses the creator’s process handle as the inherit from process handle.

The link between a creator process and a ‘child’ process has always been extremely tenuous in NT.

By: Mario Vilas

Mario Vilas — Wed, 25 Nov 2009 00:57:51 +0000

Cool

I’ve ported the tool to Python and included it in my WinAppDbg debugger: http://sourceforge.net/apps/trac/winappdbg/browser/trunk/tools/SelectMyParent.py

This trick could also be used to thwart an antidebugging trick, as some packers check if their parent is explorer.exe or not.

By: Interesting Information Security Bits for 11/23/2009 | Infosec Ramblings

Interesting Information Security Bits for 11/23/2009 | Infosec Ramblings — Mon, 23 Nov 2009 23:04:05 +0000

[...] process is. This creates a problem. Read Didier’s post to find out what that problem is. Quickpost: SelectMyParent or Playing With the Windows Process Tree << Didier Stevens Tags: ( windows [...]

By: Didier Stevens

Didier Stevens — Sun, 22 Nov 2009 21:49:18 +0000

A handle is a pointer to a pointer to a kernel object.

And I too believe that this feature merits further investigation . That’s why I posted my program so soon, so that others can play with it too.

FYI: my tool will not allow the new process to inherit handles. If you want this, change the code like this:
CreateProcess(NULL, argv[1], NULL, NULL, FALSE, …
->
CreateProcess(NULL, argv[1], NULL, NULL, TRUE, …

By: mubix

mubix — Sun, 22 Nov 2009 21:27:40 +0000

I’d like to expand on my questions that I asked via Twitter. Those being:
1. Are you able to move a currently running process under another one?
2. Are there any privileges applied to the parent/child relationship of processes?

You said that a child access the “inheritable handles”. I don’t know what exactly ‘handles’ are, but if you were able to migrate a running process under one that you created you might get some interesting permissions to it. Or say, Process A has handles H that Process B uses, if you were some how to hijack Process B or put yourself in between process A and process B, you might be able to alter the state of those handles.

But getting back to the ability of your app, for software that starts an “update” process, there might be some inheritable handles that you could get a hold of by impersonating the update process that it starts since most coders wont think about the security of child processes… yet.

Just thinking out loud.

Sweet program!