- Forum
- Windows Programming
- C++: better than system("filename")?
C++: better than system("filename")?
So, i was doing a bit a browsing for info online about running files through the
system("filename") command, and discovered that hackers/viruses can use it against you. So, is there an alternate/better/more secure way of running a file? thanks for your time!
Did you happen to read how these "hackers" (read as script kiddies) use system(...) against you? The underlying issue with the system(...) function on a windows platform is in the way that Windows looks for files, and no this is not resolved simply by using CreateProcess(...), which by the way would be the answer to your question. The safest method to do this is to designate the file you are trying to invoke by it's full path and run a Sanity Check on the binary file when you locate it. I don't think that Win32 has a native way to run Sanity Checks so that part is up to you.
... I'm a beginner, so could you explain to me a little more about how sanity checks, CreateProcess(), and what "kiddies" are in detial and mabey include some code examples for me? This would greately help me, and I appreciate your time and effort! ;)
also, what if your file may have more than one location (ex: the file is created in a location and because the program creating it is being run on a machine it wasnt cvreated on etc.) and you need to re-define that location is by having the program (or mabey there's some other method, like i said: only a begginner here) look at it's directory and use that to create the file.
ex: I have a list program i give to my mom to help here create grocery list (again, it's only an example). It's "current directory on my computer was... let's say my desktop. so: C:\users\username\desktop\programfile\program.exe
but, since it's on here computer the current directory is now: C:\users\mom\desktop\program\program.exe
so, isnstead of my username, it's now mom and the program won't know what the heck to do... how would a scenario like this be fixed?
also, what if your file may have more than one location (ex: the file is created in a location and because the program creating it is being run on a machine it wasnt cvreated on etc.) and you need to re-define that location is by having the program (or mabey there's some other method, like i said: only a begginner here) look at it's directory and use that to create the file.
ex: I have a list program i give to my mom to help here create grocery list (again, it's only an example). It's "current directory on my computer was... let's say my desktop. so: C:\users\username\desktop\programfile\program.exe
but, since it's on here computer the current directory is now: C:\users\mom\desktop\program\program.exe
so, isnstead of my username, it's now mom and the program won't know what the heck to do... how would a scenario like this be fixed?
Last edited on
Certainly, a Sanity Check is when you take a hash of a computer file, one that is pre-rendered, then run a mathmatical operation\formula against the rest of the target binary and compare the result of the formula with the pre-rendered hash. The idea is that if any part of the target binary file was changed or messed with in some way then the pre-rendered hash will not match the hash you have of the target file and you then know not to run it.
The term "Script Kiddie" is often, as in my case above, used as an insult but is really a designation of someones skill. It describes a person who follows step by step instructions, or alternativley just downloads and runs a script to accomplish a complex task, in our example hacking into a computer. This implies that the person does not actually understand the code they are using and so have a very low to non-existant skill level in programming. Malicious users are normally just kids throwing a tantrum or venting hormones and they won't have the drive it takes to learn how to write something that would damage your files or steal your data. There are of course exceptions to this, but they won't be the ones to attack your PC because you insulted them in a chat room.
If you're a beginner programmer then let's not get into networking computers just yet. What your are describing in regards to finding a file present on another PC can be accomplished with what is called a "Symbolic Link". These are like a cross between a shortcut and a pointer. Other options include but are not limited to Remote Procedure Calls, Remote Services, WinSock, Universla Naming Convention, etc. which one of these you end up choosing is mostly a matter of your particular style and comfort level.
In your example a relative path would be adequite this is the UNC option I mentioned above. When Windows is given a filename it first checks for that file in it's current path, if the file is present then the process is run and everyone is happy. If the file is NOT present then the next thing that Windows does is check the directories listed in the PATH Environment Variable, you can see what directories these are by typing "path" into a command line. The problem arrises because Windows will run the very FIRST instance of that file that it comes across. If you are trying to run a file called "MeAndMomsGrocerryListXYZ.txt" then the chances are pretty low that there will be a malicious file that has chosen that particular file name. But for something like "cls" or "pause", a malicious user can assume that a programmer is going to want to use one of these and so they might name their file one of those. Another well intentioned yet vulnerable feature to point out at this point is that Windows will automatically append certain common file extensions to commands that you pass it if it is unable to do anything with the literal string, these extensions include things like .exe, .bat and so on.
Since using the system(...) function simply passes a string to the shell, we don't have the ability to tell the OS if we ment for it to be running a command that is internal to the shell such as "cls" to clear the screen or that malicious file called "cls.exe" that some jerk dropped in your system path.
Since it was an application that you ran that called this file Windows will assume that you want to run it with YOUR credentials; this means if you are logged on to the PC as an administrator then that is what security context this new command is run under I'm sure you can see where this might be a problem. CreateProcess(...) slightley mitigates this by allowing you to designate what permissions the new process has when you assign the Security Token to it, of course passing NULL in this parameter is the easiest thing to do and will give the new process the default security permissions (yours) so this is what most people end up doing, and is why CreateProcess(...) is not actually that much safer then system(...).
The correct way to call a file is by passing the full path to the file as a literal string. For example if you want to open up the calculator you would use
*: Notice the '\\', this is NOT a typo. That slash character is called an escape character so in order to use it in a literal string we need to double up on them, single slashes become double slashes and double slashes become quadrupal.
The term "Script Kiddie" is often, as in my case above, used as an insult but is really a designation of someones skill. It describes a person who follows step by step instructions, or alternativley just downloads and runs a script to accomplish a complex task, in our example hacking into a computer. This implies that the person does not actually understand the code they are using and so have a very low to non-existant skill level in programming. Malicious users are normally just kids throwing a tantrum or venting hormones and they won't have the drive it takes to learn how to write something that would damage your files or steal your data. There are of course exceptions to this, but they won't be the ones to attack your PC because you insulted them in a chat room.
If you're a beginner programmer then let's not get into networking computers just yet. What your are describing in regards to finding a file present on another PC can be accomplished with what is called a "Symbolic Link". These are like a cross between a shortcut and a pointer. Other options include but are not limited to Remote Procedure Calls, Remote Services, WinSock, Universla Naming Convention, etc. which one of these you end up choosing is mostly a matter of your particular style and comfort level.
In your example a relative path would be adequite this is the UNC option I mentioned above. When Windows is given a filename it first checks for that file in it's current path, if the file is present then the process is run and everyone is happy. If the file is NOT present then the next thing that Windows does is check the directories listed in the PATH Environment Variable, you can see what directories these are by typing "path" into a command line. The problem arrises because Windows will run the very FIRST instance of that file that it comes across. If you are trying to run a file called "MeAndMomsGrocerryListXYZ.txt" then the chances are pretty low that there will be a malicious file that has chosen that particular file name. But for something like "cls" or "pause", a malicious user can assume that a programmer is going to want to use one of these and so they might name their file one of those. Another well intentioned yet vulnerable feature to point out at this point is that Windows will automatically append certain common file extensions to commands that you pass it if it is unable to do anything with the literal string, these extensions include things like .exe, .bat and so on.
Since using the system(...) function simply passes a string to the shell, we don't have the ability to tell the OS if we ment for it to be running a command that is internal to the shell such as "cls" to clear the screen or that malicious file called "cls.exe" that some jerk dropped in your system path.
Since it was an application that you ran that called this file Windows will assume that you want to run it with YOUR credentials; this means if you are logged on to the PC as an administrator then that is what security context this new command is run under I'm sure you can see where this might be a problem. CreateProcess(...) slightley mitigates this by allowing you to designate what permissions the new process has when you assign the Security Token to it, of course passing NULL in this parameter is the easiest thing to do and will give the new process the default security permissions (yours) so this is what most people end up doing, and is why CreateProcess(...) is not actually that much safer then system(...).
The correct way to call a file is by passing the full path to the file as a literal string. For example if you want to open up the calculator you would use
C:\\WINDOWS\\system32\\calc.exe* with which ever method you want to use. This is still not 100% full proof as someone can simply replace "calc.exe" with a malicious file, but that is why you run a Sanity Check first. We can also talk about Image Hijacking if you'd like but I think I've answered most of your questions and this is a lot of data to take in for a beginner.*: Notice the '\\', this is NOT a typo. That slash character is called an escape character so in order to use it in a literal string we need to double up on them, single slashes become double slashes and double slashes become quadrupal.
Last edited on
Thanks for the detailed explanation, that really helps me out.
Can you include an example of a SanityCheck in code for me? Also explain how it's used. That would really be awsome.
Can you include an example of a SanityCheck in code for me? Also explain how it's used. That would really be awsome.
| *: Notice the '\\', this is NOT a typo. That slash character is called an escape character so in order to use it in a literal string we need to double up on them, single slashes become double slashes and double slashes become quadrupal. |
Alternatively, a single forward slash works fine on Win in such circumstances:
C:/WINDOWS/system32/calc.exe
Topic archived. No new replies allowed.