The system() call <- why is it insecure?
Results 1 to 2 of 2

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

  1. #1
    Junior Member
    Join Date
    Dec 2007

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

    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?

  2. #2
    Senior Member
    Join Date
    Jan 2002
    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?


Similar Threads

  1. OpenVMS Fundamentals Chapter 1
    By agent.idle in forum Other Tutorials Forum
    Replies: 0
    Last Post: March 12th, 2004, 05:39 PM
  2. The history of the Mac line of Operating systems
    By gore in forum Operating Systems
    Replies: 3
    Last Post: March 7th, 2004, 07:02 AM
  3. Howto: Understand Secure Systems
    By catch in forum The Security Tutorials Forum
    Replies: 4
    Last Post: October 19th, 2003, 07:22 AM
  4. CMOS commands
    By qwerty_smith in forum Other Tutorials Forum
    Replies: 7
    Last Post: September 23rd, 2002, 06:29 PM
  5. Traceroute: under the hood
    By antihaxor in forum Non-Security Archives
    Replies: 0
    Last Post: January 24th, 2002, 04:42 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

 Security News


       Security Trends


           Buying Guides