Debugging and DLL-Injection

Question

Hi, I am currently reading Gray Hat Python to learn about Debugging and various interesting techniques for binary analysis.

So far I have learned an amazing amount of stuff (just read about DLL-Injection). Two questions though:

When two processes are running with the same (non-administrative) user:

1. Can process A simply do kernel32.OpenProcess, kernel32.WriteMemory on process B or is that only possible for a process A that runs with higher priviliges as B (i.e my debugger running as admin).

2. Why would you ever allow something like kernel32.CreateRemoteThread?

Answer 1

From the MSDN documentation for OpenProcess

dwDesiredAccess [in]

The access to the process object. This access right is checked against 
the security descriptor for the process. This parameter can be
one or more of the process access rights.

If the caller has enabled the SeDebugPrivilege privilege, the 
requested access is granted regardless of the contents of the security
descriptor.

And then if you look at the process access rights documentation you'll see that one of the access rights you can request is PROCESS_VM_WRITE which is needed to call WriteProcessMemory.

Again from the MSDN documentation for CreateRemoteThread

A common use of this function is to inject a thread into a process that is being debugged to issue a break. However, this use is not recommended, because the extra thread is confusing to the person debugging the application and there are several side effects to using this technique:

It converts single-threaded applications into multithreaded applications.
It changes the timing and memory layout of the process.
It results in a call to the entry point of each DLL in the process.

Another common use of this function is to inject a thread into a process to query heap or other process information. This can cause the same side effects mentioned in the previous paragraph. Also, the application can deadlock if the thread attempts to obtain ownership of locks that another thread is using.

Even though the documentation recommends against it. I've most often seen CreateRemoteThread used in debuggers or other types of profiling/api logging applications.

Answer 2

Calling OpenProcess requires that the current process is running under the context of a user that has an entry in the ACL of the second process. So, if you start two processes under the same user context, they can both open handles to each other with enough permissions to read and write memory. However, if the process calling OpenProcess is running under the context of an administrative user, that process may grant itself SeDebugPrivilege, which bypasses all process ACLs, such that it may access all processes for any user on the system. One caveat of this is that CreateRemoteThread won't work unless the target process is running under the same session as the calling process.

As for the rationale behind it, the CreateRemoteThread function was originally used for debugging purposes and has been kept for legacy reasons. Since then it has seen use in a variety of different operations:

• An easy way of integrating custom functionality into a 3rd party product. A lot of gaming software, such as xfire, does this. They display their own UI over a game by injecting a DLL and hooking the DirectX and OpenGL present calls.
• Some rather crude RPC mechanisms use injected threads to invoke functions in a 3rd party process.
• Anti-malware systems often inject a DLL into running processes to avoid the performance hit of functions such as ReadProcessMemory, since they can just use direct memory reads instead.
• Various anti-copy libraries (DRM) use CreateRemoteThread to inject themselves into a target in order to hook APIs that might be used to read memory from a protected process.

So, while it might constitute a minor security issue in some cases, the API is unlikely to disappear due to its versatility.

Answer 3

It depends on the OS, but in most OSes two separate processes should be kept in separate memory address spaces by the OS when running independently in user mode on most OSes. That does not necessarily mean that there may not exist exploits that could get around this limitation, but it would be a far more advanced attack at that point. There also can be various APIs to allow access to other process address spaces depending on what is permitted by the OS, but this is all OS (and potentially configuration) specific.