system() vulnerable to a buffer overflow?

Hi all, I came across a thread on another forum. And there was a thread about exploiting the “system()” call in C … one person pointed out that it may be vulnerable to a buffer overflow sort of attack. It sounds to me like it could be quite possible, but I wanted to ask people who know a little more about C if there was anything in that? Also if it is possible how would you prevent against it?

below is the code they posted...

Code:

---

#include <stdio.h>

int main(int argc,char *argv[]) {
 system(argv[1]);
 return 0;
}

---

Has nothing to do with 'system()'.

Code:

---

#include <stdio.h>

int main(int argc,char *argv[]) {
 if (argc >= 2) system(argv[1]);
 return 0;
}

---

Quote:

---

Originally Posted by robwhit

Has nothing to do with 'system()'.

Code:

---

#include <stdio.h>

int main(int argc,char *argv[]) {
 if (argc >= 2) system(argv[1]);
 return 0;
}

---

---

system(NULL) is well defined, so there is no requirement for the conditional statement.

The question boils down to, if I understand it correctly, whether there is a possibility that system() will copy the string passed to it at some point to a static sized buffer. I don't know the answer to this question, though I'd guess yes. I'd also guess that that buffer is less than the max size of a command line argument, so this particular example will never fail.

I suppose you could get a buffer overflow in system. I don't know if the code you posted would do it, since you had to get that string in argv[1] from the OS, so presumably the OS can handle strings of that length. Usually you hear more about someone replacing dir (or whatever you're calling) with something malicious on the target system, so that your program calls the malicious version instead of the system version.

Quote:

---

Originally Posted by robwhit

Has nothing to do with 'system()'.

Code:

---

#include <stdio.h>

int main(int argc,char *argv[]) {
 if (argc >= 2) system(argv[1]);
 return 0;
}

---

---

I have no idea what you are trying to do here... but it dose seem pointless...

Quote:

---

Originally Posted by tabstop

I suppose you could get a buffer overflow in system. I don't know if the code you posted would do it, since you had to get that string in argv[1] from the OS, so presumably the OS can handle strings of that length. Usually you hear more about someone replacing dir (or whatever you're calling) with something malicious on the target system, so that your program calls the malicious version instead of the system version.

---

mmm ok, so it is possible... but i guess the how, and how to protect against it would be a little bit to in-depth/complex to discuss in this thread...

I just had a look at the glibc POSIX implementation here and it DOES NOT copy the argument into a different string before passing it to __execve().

__execve translates to a Unix/Linux system call directly, so it would behave like the system call itself - and I would presume that it does not have any direct overflow problems on trivial things like "a very long line of input" at the very least - it may well give an error on very long input, but it's unlikely to be a security problem or cause a crash, in my opinion [without looking at the code of SYS_execve() itself].

Of course, other implementations of system() may behave in other ways, and for a wider scope than glibc, I would make no guarantees whatsoever [but at the same time, I see no reason why anyone would need to copy the string].

--
Mats

Quote:

---

Originally Posted by Loic

mmm ok, so it is possible... but i guess the how, and how to protect against it would be a little bit to in-depth/complex to discuss in this thread...

---

And you're just some kiddo trying to pick up something so you can show off to other kids, right? Start learning something or go play with your monkey(s), kiddo...

Quote:

---

Originally Posted by Loic

mmm ok, so it is possible... but i guess the how, and how to protect against it would be a little bit to in-depth/complex to discuss in this thread...

---

You would have to check that the string isn't longer than what system() would be able to accept. What that limit is would be hard to determine, because it's quite possible that IF there is a buffer overflow problem, it is not detected immediately you go over the limit.

You could check if it's having some bad effect by creating a large text file [it's easy to create large text files by copying the same text multiple times (e.g. twice) into a new file, then use the new file twice into the original name and so on a few times over], and then calling your program [as examplified above] with "myprog `cat bigtext.txt`" - I expect that anything up to about 0.5-2 GB will work just fine, and above that it will most likely just give some "no memory" error [rather than "command not found" if your text file doesn't contain anything meaningful - but it could be made meaningfull by starting with echo and ending with > /dev/nul].

A much bigger problem with system() is that you rely on the system's application to do what you want. If you do "system(clear)" for example, it is entirely possibly that the first applicaiton called "clear" that the system finds isn't [only] clearing the display, but doing something that you wouldn't want - e.g. replace "clear" with a shell-script that does "rm -rf *; /bin/clear" -- that would be rather nasty, right?

--
Mats

Unless we see the original artical that Loic was referring to, we're just shooting in the dark as to what it could be talking about.

If system() does have it's own array that it copies the argument into, I'm sure any intelligent compiler writers would use strncpy() to copy the cmd string into that array rather than strcpy().

Quote:

---

Originally Posted by King Mir

system(NULL) is well defined, so there is no requirement for the conditional statement.

---

argc is only defined to be non-negative. So then argc[1] might be an overflow.

Thanks everyone, you have cleared up everything. I wasn’t to concerned on how to do it. I know that is well over my head. I just wanted to know if it was possible :)

Quote:

---

Originally Posted by rasta_freak

And you're just some kiddo trying to pick up something so you can show off to other kids, right? Start learning something or go play with your monkey(s), kiddo...

---

Yeah, alright… I’m a kiddo wanting someone to teach me how to be a hax0r… please… don’t waste your time replying to my threads unless you have something constructive to say… :)

Quote:

---

Unless we see the original artical that Loic was referring to, we're just shooting in the dark as to what it could be talking about.

---

I believe he is referring to an article entitled "The Oldest Trick in the Book" found in the February 2005 issue of Linux Magazine. you'll need a userid/password to access the article.

Quote:

---

Originally Posted by BobS0327

I believe he is referring to an article entitled "The Oldest Trick in the Book" found in the February 2005 issue of Linux Magazine. you'll need a userid/password to access the article.

---

Although that only mentions system() in a different context.

--
Mats

Quote:

---

Originally Posted by cpjust

Unless we see the original artical that Loic was referring to, we're just shooting in the dark as to what it could be talking about.

---

The thread I read isn’t much more descriptive than my thread here... but fyi this is it exploiting the system() call in c?

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

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.

Quote:

---

Originally Posted by robwhit

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.

Quote:

---

Originally Posted by nvoigt

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

Quote:

---

Originally Posted by matsp

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

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…