The system() call <- why is it insecure?

[theoperator]

From the manual page of "system", on a Debian GNU/Linux system:

Do not use system() from a program with set-user-ID or set-group-ID privileges, because strange values for some environment variables might be  used to  subvert  system integrity.

Now, I *thought* I understood why system is insecure and that programs that make use of it can be /exploited/ via custom PATH and IFS variables as follows:

#1. We have an "insecure" executable binary, let's say it is NOT SUID/SGID, for now. insecure calls "system("/bin/ls");" at some point.

#2. We create the directory "exploit" and we `cd` to it. In this directory we make the executable "bin" which simply prints "Hello, world!" to the screen. It is this executable we are trying to make `insecure` execute.

#3. We change IFS to "/" and PATH to "exploit" via: export IFS=/ && export PATH="/some/dir/exploit".

#4. Right now, the / character should delimit command line arguments rather than the default 'whitespace' option, so : /bin/ls, by this rule would actually mean: "run bin with the first argument ls". Our path is the exploit directory so running `bin` without specifiying the full path should work.

#5. In other words, running /bin/ls should actually run our `bin` executable and pass `ls` as it's first argument. Thus we should be able to exploit the system() call in our insecure program.

#6. We run `insecure` and expect to see "Hello, world!" on the screen rather than a directory listing.

However, this does not happen (we get a directory listing rather than the hello, world message), and I don't understand why. So I guess this means I actually do *not* understand why system() is insecure, could anyone enlighten me?

[slarty]

Most uses of the system() function will be incorporating user supplied data in some way into the command line.

If this isn't checked or escaped very carefully, it will be possible that a malicious user could use it to cause arbitrary program execution with the privileges of whatever the program was doing (this could be a network server, in which case it will be a potential remote exploit).

Also the IFS exploit described should work.

Generally speaking, any setuid program should be clearing its environment variables immediately (unless there are specific ones it wants to keep- certainly not IFS).

Does running /bin/ls directly from the shell after setting IFS do what you expect?

Mark