Why is it bad to use system() in linux programming?

Question

Possible Duplicate:
Issuing system commands in Linux from C, C++

I see on some text that it is not good to use system() call in linux programming, I wonder what are the real reasons of it? It should consume more memory and maybe more CPU. Apart from these what could be the reason?

For example, if I type system("echo 1 > file"); instead of using fopen(), fwrite() what a hacker can do in my program/linux system? I saw that system() is not advise because of security issues. But how a person can hack a linux system just because of using system() call? I would be glad if someone can explain tangibly what could go bad to use system().

[Why system() is bad](http://stackoverflow.com/a/4622772/1275169) — P.P, Jul 09 '12 at 13:10
it would be more constructive to explain the reason rather than minus the question — johan, Jul 09 '12 at 13:10

score 7 · Accepted Answer · answered Jul 09 '12 at 13:12

7

Using system("echo 1 > file"); literally isn't a security risk, just a needless execution of another process where you don't need one.

The risk comes in when you build a string programmatically and then use it with system(). Then you have a risk of Shell Command Injection, where you thought you were building one command, but a malicious user subverts your program by giving you carefully crafted inputs that cause your command to do something you didn't expect.

answered Jul 09 '12 at 13:12

Ned Batchelder

364,293
75
561
662

Thanks for the explanation, it makes more sense now – johan Jul 09 '12 at 13:15
5

Even `system("echo 1 > file")` **could** be a security risk, depending on how it's run. As an example, if `PATH` is set to something bogus, `echo` could be a program different than the standard echo command. Even if not, there are all sorts of environment variables that could affect what the shell and/or echo might do. This could cause your program to misbehave, and if it's suid, it could easily yield privilege escalation. Moreover, there's no good way to *check for failure* of storing "1" in "file", and not checking for failure is always a bug and often a security risk. – R.. GitHub STOP HELPING ICE Jul 09 '12 at 14:01

pgpython · Answer 2 · 2012-07-09T14:01:29.857

The problem is that you are trusting the string passed into system to be safe from a trusted source. Suppose you had something like this:

char *command = null;
//Read command from external source;
system(command);

would you able to trust command was safe and not to do something nasty like "rm -fr ~/*" ? Using fopen doesn't make you necessary safe either though because again a hacker could just pass in a name of file such /etc/passwd and read that which you don't want. the bottom line where you program interfaces with the outside world. that is where you to put in some validation and restriction to what an external user can do

score 1 · Answer 3 · answered Jul 09 '12 at 13:22

System(3) starts another process and runs a command interpreter ("/bin/sh -c") to execute your command. This can be a problem if your program is running with a SUID or SGID bit. The behaviour of the shell is controlled by many environment variables and some of these may be used to gain control of the command interpreter. This situation is similar to executing a SUID or SGID shell script.

Why is it bad to use system() in linux programming?

3 Answers3