Cracking System()

[Computergeek01]

I would like to start by saying that I'm posting this in the Begginer section because I feel like a Noob asking it.

Question: How does the system() function "talk" to the OS?

Objective: To see how system() talks to the OS. I want to know a few things:
- Why is system() said to be "insecure"?
- How much overhead is this function REALLY adding to my process?
- Given this data could I write a better function for my purposes?

My Level: I've been teaching myself C++ for 10 yrs, I've not written profesionally.

I would be happy with a link that would answer my questions

[firedraco]

http://www.cplusplus.com/forum/articles/11153/

[Computergeek01]

Thanks firedraco, that was informative.

So I see that the security issues are valid but a little overblown. If you think this is bad you would have a heartattack reading Rootkits by Greg Hoglund & James Butler which is a great book that I very much recommend for anyone in entry to intermediate level IT.

Question: Can someone point me to which lib system() uses? Or does it talk right to a DLL? I want to see if I can talk directly to the OS without the system function. I'm self trained so I miss use terms at times, please forgive that.

Objective: The OS has certain information (User name, OS version etc.) that could be of use to a programmer. Right now the system() function is the best way I know how to get that information (See below if you have a strong stomach for hack job code :p).

Quick Example:

...// Blah blah start of program.
{
system("DIR >> t.txt"); /* DOS+Windows command to output results of DIR to file t.txt in current directory */

...//Test to see if t.txt exists

ifstream datain("t.txt", ios_base::in); //Feed results of DIR to datain variable

...//Do whatever with datain

ofstream dataout("Some.bat", ios_base:::trunc); /*Write a DOS+Windows batch file using ios_base::trunc to overwrite the file if it already exists*/

dataout.close(); //Close dataout so that Some.bat is ready to execute

system("Some.bat"); //Execute batch file by having system() function call it

system("del Some.bat"); //Clean up after yourself

return 0;}

Thoughts: Why do I feel like this post is going to get me crucified on this site?

[helios]

Can someone point me to which lib system() uses?

Depends on the system. I don't know about UNIX, but on Windows it's just a call to CreateProcess(), I believe.

That's a terrible way of doing it. The correct way would be to use system calls to list the files in a directory, or whatever you're trying to do. There's always a way of doing it that doesn't involve system(). Google is your friend.

[moorecm]

In POSIX systems, I think there is an API function that can start a process. I think that system() actually creates a Borne Shell and passes the user supplied command as a parameter to it. I just snooped around sysdeps/posix/system.c in glibc for a minute and that's about all I can come up with. It's hard to follow.

[Duthomhas]

So I see that the security issues are valid but a little overblown.

So you are saying one security hole elsewhere validates security holes in your own code? You don't understand secure computing.

Can someone point me to which lib system() uses?

Each OS is different. The system() call is usually a little more complex than most because of the hoops it has to jump through to conform to the standard.

I want to see if I can talk directly to the OS without the system function.

Of course you can. You just need to #include <appropriate> headers and, depending on what you are doing, link with -lappropriate libraries.

Since you are obviously on Windows, you should head over to MSDN for all the information you need for programming with the Windows API. Google's "I'm feeling lucky" button is also very good for getting information about specific functions. For example, if you Google "msdn CreateProcess" with the "I'm feeling lucky" button, you'll be directed here:
http://www.google.com/search?btnI=1&q=msdn+CreateProcess

Playing with the system API is always a bit more complex than playing with a fancy interface like the command shell. In this regard, various C and C++ libraries have been written to make doing stuff like that easier. Google "c++ application framework" for some good stuff.

Finally, if all your code is doing is calling various system routines, why use C++ at all? Why not just write yourself a nice, big batch file or wsh (Windows Shell) script? Other languages you might find more to your liking include Python, Tcl, and JavaScript.

Good luck.

[Computergeek01]

I appreciate the advice here people, I plan on following up on the suggestions made from all of you even if I feel like it's a road I've been down before. That's how bad I want to break this reliance on the system() function.

Batch files have horrid logic; and if then goto statements are not a ready subsitute for a logic loop.

@ Duoas: The shot at me not understanding "secure computing" was a little mean, I've read your answers to other users and I respect your talent for this so I do not want to scorn or belittle you in any way but I feel this response is needed. I could argue that you're unreasonable to think that the system you're operating on is not reliable. If that's the case then why use an high level language at all? Why not code your own DLL's in assembly? Then you should package them with your programs and start only your copies into memory to avoid "DLL-hell". Why not hijack ring 0 everytime your stuff runs because SOME of the users MIGHT have a rootkit? You could virtualise\sandbox an enviroment for every "Hello World" process you write with a checksum bit included in every iteration. But you don't have to, because it's impossible to account for every stupid little thing the end user has done AND WILL do to their computer, so why try to get around any of it? You write in C or C++ as well as an impressive number of other languages, so you are already assuming that your program and its libraries will use operations whose functions work even on non-X86, non-X64 processors such as ARM. At what point do you trust your program to just work?

There are basic things that every programmer should take into account and platform delvelopment is one of them, but I'm working on Windows now with expectations to branch into (X)nix soon after, so I know where I am.

[tummychow]

The reason that Duoas told you that system() is insecure is because it is, and because it is easy to avoid. There's no need to get worked up; he's stating fact. The thing is that system is an obvious, easy to exploit hole that can easily be countered by not using it. There are always superior means, although they may be API-specific. (system is pretty OS-specific anyway so it's not a major difference if any.) It's not that the system being used is unreliable - it's the RISK that system() will create an insecure call. So the security *can* be overblown, but only in the case of minor programs that you're writing for no serious cause. In actual professional programming, system() is a *risk* not worth taking, and the possibility of risk is simply too high for the minor reward. If there was a serious advantage to using system over some other method then the call would be mitigable, but there isn't, and that's why it's a security risk that should be taken into account.

[Computergeek01]

I hope I don't cause much trouble with this but here we go.

Since my earlier days programming I have ALWAYS wondered about this insecurity. I can tell you with certainty that after running C++ programs with system calls in debug mode as well as watching them with Ollydbg, and trying, that there is no obvious way to exploit system() calls.

-I can understand if the function you are calling has been compromised that calling it could be bad. You get one point for that one.

But within your program:
- Buffer over runs into the part of the memory holding the system call, if you can cause them to happen at all, do not occur without serious crashing of the program before hand which is neatley handled by major OS's.

- Further more in the off chance that an overrun is allowed through, system() is not capable of passing information about what memory page it is allocated to back to its program directly, so usage of this technique is limited.

- I have not found any SQL injection like exploitations with getline or cin (I assume these are the major ones used). fstream is a different story, I will conceed a minor point to you on that one.

- system() passes static text so cannot change the user that is running it with any "runas" tricks for example.

- system talks to the OS so memory allocation is still done dynamically and access to restriceted books, pages etc is still preserved.

I want to ditch system() because of its OS dependencies and inability to handle variables.

[helios]

there is no obvious way to exploit system() calls.

No? Okay, how about this: Your program calls system("dir"), and I put a program called dir somewhere in PATH that does X.

[firedraco]

Well, the fact is that compromising the program you are calling IS a huge hole. All they need to know is what command you are executing to screw you over.

[moorecm]

I think its just being suggested that if someone already has access to replace a command, manipulate a symbolic link, etc. that security has already been compromised. Not that I'm advocating the use of system to compound the problem or anything...

[kevinkjt2000]

moorecm does bring up a good point... You would be screwed if somebody had access to such important system directories. The only real reasons for avoiding system is just because it is so OS specific and if you want to optimize for speed. Why can't system just be removed? None of the more advanced programmers ever touch it and it is so easy to implement with a short amount of code in C++.

[tummychow]

System IS easy and obvious to exploit. That's why you shouldn't use it. EOF.

[Computergeek01]

Yes helios, you're right if I code system("dir") like an amatuer then (for DOS based OS's) the command shell will first look in the directory that it is operating in and if you happend to drop a file called dir in there then it would be executed. This is why we hard code paths, system("C:\WINDOWS\dir").

Look I'm not defending the use of system(), see the title of the post. What I was wondering is if it is so easy to accomplish the same things that system calls do with out using it, then why is the documentation buried? I've discoverd some good stuff based on the post from Duoas and helios. moorecm basically told me in his earlier post that it behaves the same for *nix as it does for Windows so it's just a function that passes a string to the OS.

[helios]

C:\WINDOWS\dir

a) There's no such program by default.
b) You can't know where the Windows directory is in a particular installation (without accessing the registry).
c) Even if there was such a program there, you can't know that it's the one you expect.