RhInjectLibrary causes modification to the PATH environment variable

May 6, 2013 at 9:18 PM
If this has already been brought up or addressed in another thread or issue, please let me know...

I noticed that when calling RhInjectLibrary, the PATH would always be modified to include the path to the EXE which invoked RhInjectLibrary. Further investigation found the culprit in entry.c (in HookCompleteInjection).

My question is; why is PATH modified by EasyHook upon remote injection through RhInjectLibrary? Walking the code path, I could not come up with a concrete reason. To me, this seems like a bug. The hooking library should not modify the state of the process' environment block. The hooking library should cause as little commotion as possible.

Consider the use case where you hook the CreateProcessA/W APIs and want to daisy chain hooking (so that all processes spawned henceforth are hooked). If a hooked process either:

A). does not specify an extension for an executable it wants to spawn through its call to CreateProcessA/W
B). specifies a relative path as the application to spawn

Windows will use the PATH to resolve the executable to spawn. If the hooked process which is trying to invoke this process has a similarly named process in its working directory, the (potentially) incorrect EXE will be spawned due to the PATH being modified. To try to illustrate a little better...

PATH is set to "C:\foo" which contains foo.exe in it.
Process A has a working directory of "C:\bar" and this directory has a different version of foo.exe in it.
Process A's CreateProcessA/W APIs were hooked by RhInjectLibrary. Hence the PATH is now set to "C:\bar;C:\foo".
Process A calls CreateProcessA, passing in only "foo" as the application to spawn.
Windows reads the PATH, takes the first path on the PATH, finds foo.exe (which is not the one which Process A intended to spawn) and executes it.


I am curious as to whether there is a solid use case for RhInjectLibrary modifying PATH.


Thanks,
Jeff