Is it possible for one process to inject code into another without administrative privileges?
Asked Answered
A

2

7

The CryptProtectMemory API in the DPAPI allows you to pass the CRYPTPROTECTMEMORY_SAME_PROCESS flag, which prevents other processes from decrypting the memory. One way around this would be to use OpenProcess, WriteProcessMemory, and CreateRemoteThread to inject code into the target process and have it call CryptUnprotectMemory, thus decrypting the memory and leaking it to the other process.

Assuming both processes are running under the context of the same limited privilege user (i.e. not an administrator) on Windows Vista or later, is this still possible? I was under the impression that process memory write operations were denied to limited users, regardless of the process ACL, but I may be wrong.

Abri answered 27/1, 2013 at 23:44 Comment(4)
No need to elevate to inject with CreateRemoteThread. See my question here: stackoverflow.com/questions/12180732Laidlaw
If this can be done to unrelated processes (running with another user's privileges), it is time to get that fixed real fast.Animal
@vonbrand: Users have always had permission to debug processes they own. How would you suggest "fixing" this?Weever
@vonbrand: no, the default ACL only allows access to local system, the user the process is running as, and the logon SID for the current logon session.Eldoneldora
E
2

Windows respects the process ACL, and by default, this allows access to the user the process is running as as well as to the local system account and the user's logon session SID. Administrators can bypass this ACL using SeDebugPrivilege.

Otherwise, you would need to be an administrator in order to debug your own code.

You can change the process ACL, but since normally (IIRC) the current user is the process owner I'm not certain whether or not you can prevent another process in the current user context from changing it back. Also, since it is likely that the processes are running on the same desktop, you would be subject to shatter attacks anyway.

Eldoneldora answered 28/1, 2013 at 0:55 Comment(1)
Actually, administrators are usually not allowed in the process ACL. But Administrators can usually take SeDebugPrivilege which allows them to "go around" the ACL.Weever
H
2

You don't describe the exact scenario in which you need to use code injection. If ope process running without administrative rights create another process with respect of CreateProcess for example one get handle on the new process with all rights PROCESS_ALL_ACCESS (hProcess of PROCESS_INFORMATION). You can read here for example the following

The handle returned by the CreateProcess function has PROCESS_ALL_ACCESS access to the process object.

So one should just hold the handler returned from CreateProcess and don't close it till you need to have full access to the child process. In the way you will have PROCESS_CREATE_THREAD, PROCESS_QUERY_INFORMATION, PROCESS_VM_OPERATION, PROCESS_VM_WRITE, and PROCESS_VM_READ access rights required to call CreateRemoteThread and WriteProcessMemory.

So the answer on your question will be: "Yes, it's possible under some additional conditions".

Helicoid answered 2/2, 2013 at 10:44 Comment(5)
I don't think the OP wants to use code injection, he wants to prevent another process from using code injection against his one.Eldoneldora
@HarryJohnston: It doesn't matter. If his program will be started directly by another process with respect of CreateProcess the owner process will have full control over the created process. So one do can make code injection.Helicoid
Seeing as you can generally do code injection anyway, I'm not sure that it makes much difference. But this is indeed another example of why changing the process ACL doesn't solve the problem.Eldoneldora
@HarryJohnston: I don't test it myself, but I think that ACL will be verified before creating the handle with some permissions. The handle for CreateProcess will be created event before the process start running. For example one can use CREATE_SUSPENDED flag to create the process before it will be running at all. One do this for example if one want to place new process inside a Job using AssignProcessToJobObject. So I don't think that the new process can change it's ACL to protect itself from DLL Injection of the parent process having PROCESS_ALL_ACCESS on it.Helicoid
I don't think the ACL gets checked at all with regards to the handle returned from CreateProcess, i.e., you still get PROCESS_ALL_ACCESS even if the default ACL wouldn't allow access (which might be possible in some scenarios). So I agree that you can't protect yourself from your parent.Eldoneldora

© 2022 - 2024 — McMap. All rights reserved.