system() vulnerable to a buffer overflow?

This is a discussion on system() vulnerable to a buffer overflow? within the C Programming forums, part of the General Programming Boards category; I very much doubt there is anything you can do to gain privileges, unless "exploitme" itself has suid privileges [and ...

  1. #16
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    I very much doubt there is anything you can do to gain privileges, unless "exploitme" itself has suid privileges [and there is no reason for such an application to be given suid].

    In the example given by Jon Erickson in Linux Magazine, the application is given suid privileges, and after that, the stack overflow is used to make the application propagate those privileges to other functions in the system, for example by calling system(). But system in and of itself is not a function that can be exploited [at least as far as I can determine by reading the source of it].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  2. #17
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,138
    Giving totally unfiltered user input to a system call is not an exploit, it's pure stupidity. Don't use system() if you don't have to, read the FAQ on why it is bad. Thinking about exploitable holes in system() is like looking for dangerous parts on a tank. It is the dangerous part.
    hth
    -nv

    She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."

    When in doubt, read the FAQ.
    Then ask a smart question.

  3. #18
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    Quote Originally Posted by robwhit View Post
    argc is only defined to be non-negative. So then argc[1] might be an overflow.
    True, except for POSIX systems, where argc must be positive, and argv[argc] must be NULL.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #19
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by nvoigt View Post
    Giving totally unfiltered user input to a system call is not an exploit, it's pure stupidity. Don't use system() if you don't have to, read the FAQ on why it is bad. Thinking about exploitable holes in system() is like looking for dangerous parts on a tank. It is the dangerous part.
    Yes, but it's system() itself is not in itself allowing privilege elevation - it allows the user to specify what else to run, but the general principle of privilege elevation is that you need to find a way to get into an application that already has privilieges that you wish to (ab)use. So a privileged applicaiton using system() would be a bad thing [because the user could change what system actually does, either by substituting what is passed into system, or by modifying/substituting the executable run system() in itself].

    It's a bit like your analogy of the tank - it is only dangerous if you are OUTSIDE the tank. Inside the tank is quite safe [relatively speaking]. In the same way, a non-privileged application is quite safe [towards the rest of the OS], whilst the dangerous applications are those that have privileges. If you can somehow find a way to make a privileged application perform YOUR tasks, then you have [essentially] achieved unrestricted privileged access.

    But the function system() in itself does not give privileges.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #20
    Registered Abuser Loic's Avatar
    Join Date
    Mar 2007
    Location
    Sydney
    Posts
    115
    Quote Originally Posted by matsp View Post
    I very much doubt there is anything you can do to gain privileges, unless "exploitme" itself has suid privileges [and there is no reason for such an application to be given suid].

    In the example given by Jon Erickson in Linux Magazine, the application is given suid privileges, and after that, the stack overflow is used to make the application propagate those privileges to other functions in the system, for example by calling system(). But system in and of itself is not a function that can be exploited [at least as far as I can determine by reading the source of it].

    --
    Mats
    I read over that article your posted "The Oldest Trick in the Book" cleared every thing up... i now have a much better understanding on how fuzzing, buffer overflows... and how a systems works... cheers for that...

    Quote Originally Posted by nvoigt View Post
    Giving totally unfiltered user input to a system call is not an exploit, it's pure stupidity. Don't use system() if you don't have to, read the FAQ on why it is bad. Thinking about exploitable holes in system() is like looking for dangerous parts on a tank. It is the dangerous part.
    From what I can understand from that other thread, it was done on purpose. Like a lab exercise…

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. clear buffer
    By justins in forum C Programming
    Replies: 5
    Last Post: 05-19-2007, 06:16 AM
  2. buffer overflow
    By cpp_is_fun in forum C Programming
    Replies: 2
    Last Post: 10-24-2006, 11:04 PM
  3. Buffer overflow? Won't join channel sometimes -- IRC Bot in C
    By Apocalypse in forum Networking/Device Communication
    Replies: 3
    Last Post: 01-17-2006, 10:00 PM
  4. Replies: 4
    Last Post: 06-13-2005, 09:03 AM
  5. Does anyone Know How to..?
    By kwigibo in forum C Programming
    Replies: 12
    Last Post: 09-20-2001, 08:16 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21