cadouthat

ive been messin around with threads and processes and stuff lately (i was just curious) and i found a function called createremotethread(), it is supposed to make a new thread in another process, but even when i set everything up right, the process i create the thread in "has an error and needed to close"... i checked the exit code and it had to do with access rights - does this mean that there is no way to make a thread in another process that would make createremotethread useless, so how do i get it to work do i need a certain privilege i guess it dosent matter that much because i was just messing around but now that i started i want it to work....

thanks in advance

PS i assure you i am not making anything malicous, i just wanted to make something new and different




Re: Visual C++ General createremotethread

einaros

CreateRemoteThread works quite nicely, but it does require you to make whatever parameters and functions you call available to the remote process. If you could paste the code you attempted to run, it would be a whole lot easier for us to spot the problem :)




Re: Visual C++ General createremotethread

Simple Samples

 cadouthat wrote:
PS i assure you i am not making anything malicous, i just wanted to make something new and different
This might be the answer to your question. It is a huge security problem if a program can execute code in another process that is trying to protect it's data and such. Therefore it is a good thing that you can't do it.

Einar is certainly correct that the problem could be that data used by the caller of CreateRemoteThread is not accessible to the other process. If that is the problem then you probably need to use Interprocess Communication (IPC) to exchange data.






Re: Visual C++ General createremotethread

einaros

Simple Samples wrote:
If that is the problem then you probably need to use Interprocess Communication (IPC) to exchange data.

Either that, or WriteProcessMemory. Usually you'll use CreateRemoteThread to either call library functions you *know* exists in the target image, such as those of kernel32, or inject your own data. This data can e.g. be the name of a dll, which you force the remote process to load by spawning CreateRemoteThread on LoadLibrary, with the location of your injected library name (in the remote process' memory) as parameter.






Re: Visual C++ General createremotethread

Simple Samples

WriteProcessMemory is used and recommended by many developers but it is not included in the IPC area of the SDK. It is a debugging function and therefore requires debugging privileges. I don't know how common or uncommon it is for a typical non-developer employee's account to have debugger priviliges but it seems to be undesirable.

I have asked many, many times in security and Windows programming newsgroups and forums why WriteProcessMemory is not considered to be a valid IPC mechanism but the only answer I get is don't do it. If I ask why, the person might get upset that I don't accept their answer.

In this context, WriteProcessMemory is good because it is easy and this is only for educational purposes. Other techniques can be explored later. I hope it helps though to know that WriteProcessMemory is a debugging function.






Re: Visual C++ General createremotethread

einaros

It's intrusive, that's one reason I can think of :) I wouldn't recommend trying to write to processes other than those spawned by the current one. It's not that it would for sure cause problems, but it *may* affect the target application in undesired ways, so it should be considered good practice not to write to anything and everything.

Also, with processes not spawned by the current proc, the access issues may complicate things. I don't think you need to enable the debugging rights to use WriteProcessMemory, though. Or rather, if you've got the necessary rights to call CreateRemoteThread on a process, it's safe to assume that you can write to it.






Re: Visual C++ General createremotethread

Simple Samples

I will refrain from saying too much; if Brain Kramer sees this, he will close it immediately. I of course am very happy to continue elsewhere or directly by email.

WriteProcessMemory of course is acceptable to the developer of the application that uses it. The main problem is that the manager/owner of a system has reason to avoid software that uses it.






Re: Visual C++ General createremotethread

cadouthat

i tried writeprocessmemory, but i dont understand, what am i trying to accompilish, what am i writing to the memory

anyway, i have already given my process debug privs when i call the functions, so i had no errors about access denied or anything....

when you said its a huge security problem, thats my point, if it is a security risk why does it exist if it exists there must be a way to get it to work....

oh well, i was just messin around so i guess ill just give up, unless you guys have any ideas other than having debug privs






Re: Visual C++ General createremotethread

einaros

cadouthat wrote:

when you said its a huge security problem, thats my point, if it is a security risk why does it exist if it exists there must be a way to get it to work....

It's not as much as security problem as an integrity problem in my eyes. Since you've already got the needed access to the applications running in context of your own user, it doesn't matter much if you can or cannot runtime patch -- you could always change the file itself.

That being said, it's a very handy function for several reasons. Obivously for debugging puprposes it's an absolute must have, but there are also situations where you *do* want (and have sound reasons to) change the behavior of an application at runtime. I use this technique in conjunction with e.g. QueueUserAPC in a couple of my local system tools, where I go ahead and force the inclusion of custom libraries as another process is being spawned. In these situations, it's crucial that my library is loaded prior to any initialization code run by the target process, so relying on hooks would be no good.

Anyway, what you need to do is first allocate a piece of memory in the remote application, e.g. 14 bytes to hold a filename, then WriterProcessMemory a string into that position, such as "something.dll\0", then pass this remote pointer as parameter to CreateRemoteThread. The function you would have CreateRemoteThread call could be the returned address from GetProcAddress("kernel32", "LoadLibraryA").






Re: Visual C++ General createremotethread

Simple Samples

cadouthat wrote:
when you said its a huge security problem, thats my point, if it is a security risk why does it exist if it exists there must be a way to get it to work....
You can write a program that deletes all files in the Windows directory but you should not do that just because you can. You can jump off a cliff but please don't.

The fact that it exists does not mean it is safe. Just as you must decide what to do and not do, developers and administrators must not act blindly.

It is a security risk (if allowed to be abused) if a program can spy on another program without the owner's and administrator's knowledge. Passwords could be stolen. If a program is allowed to alter the memory used by another application, it is entirely possible that a smart programmer could divert thosands or even millions of dollars to a different account. Auditors would (should) certainly be concerned about such activity and I sure can't see how such a thing could pass Sarbanes-Oxley (a federal auditing regulation in the USA).






Re: Visual C++ General createremotethread

einaros

Simple Samples wrote:

It is a security risk (if allowed to be abused) if a program can spy on another program without the owner's and administrator's knowledge.

If an attacker has the ability to call WriteProcessMemory to one of your processes, or even an administrative task, it's not the fact that the debug API is present that will bring you to your knees :) At that point the damage has already been done in terms of a system breach, and an attacker could patch files, patch your os, possibly introduce drivers which would completely disregard any restrictions put on the usermode debugging functions and so forth. That's why I like to think of Read/WriteProcessMemory, and the related APIs as more of an integrity risk in the sense that they may render target applications unstable, even through completely legitimate use.






Re: Visual C++ General createremotethread

Simple Samples

 einaros wrote:
an attacker could patch files, patch your os, possibly introduce drivers which would completely disregard any restrictions put on the usermode debugging functions and so forth.
No, NTFS security provides the ability to protect files, which also protects the operating system and such. Viruses and other malicious software would be much more dangerous if there was no way to protect critical files such as that. The problem is that Microsoft has not emphasized and explained to users what needs to be done to keep their system safe. If an attacker does not need Administrator privileges to do anything then there would be no need for them to obtain Administrator privileges.




Re: Visual C++ General createremotethread

einaros

Simple Samples wrote:

No, NTFS security provides the ability to protect files, which also protects the operating system and such.

Yes, but your current context is likely to have rights to reset those protections as it sees fit. Again, having access to Read/WriteProcess is unlikely to be your biggest concern. If you went ahead and closed those, you'd also have to completely disable windows hooks, as those are just as potent in terms of process breach. Not to mention QueueUserAPC, and various registry locations from which dlls are automatically loaded :-)

In either case, Vista addresses these issues (at least to some extent).






Re: Visual C++ General createremotethread

aao123

"...The problem is that Microsoft has not emphasized and explained to users what needs to be done to keep their system safe ..."

I completely agree with that. However I'd like to add it is Microsoft's irresponsible approach to distribution that adds to the problem. First of all most of Microsoft¡¯s own software requires admin privileges during installation. Second Microsoft¡¯s obsession with DLLs (COM and .NET included)  that they pretty much imprint on any Windows developer. Look at this news group - 50% of the posts are like "... I do not know what I depend on ...¡±, "what dlls do I need to run...". Just another day there was post from somebody distributing 50(!!!!!!) dlls. Today almost nobody even considers static linking, and almost everybody distributes huge MSI, for no other reason than Microsoft suggests it.  Mark Russinovich's Sysinternals produced wonderful and relatively complex utilities for years, most of them just drop and use. If he did not have to create humongous MSIs I bet most of the programs out there do not need it either.





Re: Visual C++ General createremotethread

cadouthat

i tried the whole thing with kernel32s loadlibrarya function, there are no errors but the dll does not execute.....

also, einaros, you said something.dll\0 what is the \0 for

anyway, i tried adding \0 and still nothing happens