CODEWITHSUNDEEP
clinuxbashunixglibc
NP Rooski Z
NP Rooski Z

Reputation: 3677

Is glibc's system() call safe?

I over heard someone saying that system() call from libc is not safe.

One reason i can think of is that it launches shell utility e.g. /bin/bash and if system("rm -rf $input") is started and $input is un-sanitized user input then it can potentially wreck havoc if $input="/". What are the other reasons?

Upvotes: 2

Views: 2025

Answers (4)

sepp2k
sepp2k

Reputation: 370425

You don't even have to call rm for malicious input to erase the hard drive. If you execute system("harmless_command $input") and $input is ; rm -rf /, that will execute harmless_command followed by rm -rf /. So if you want to interpolate user input in a command and malicious input would be a problem¹, using system would be a bad idea.

In addition to security concerns, using system can also lead to bugs. For example if you do system("some_command $filename") and $filename contains spaces (or other shell meta characters), the command will blow up unless you properly escape the file name first.

If you use the exec* family of functions (which take an array or variadic argument list containing the arguments of the command, instead of a single string that goes through the shell), none of these problems exist.

¹ In cases where the code runs on the user's computer with the user's permissions, one could argue that malicious input wouldn't be a problem. If the user enters malicious input which causes his hard drive to be erased, that's really the user's own fault. But if the code runs on a remote server or locally with enhanced permissions, it's a different matter.

Upvotes: 3

Cloud
Cloud

Reputation: 19331

That is a general case of input sanity checks. Any strings you work with should have a generic parser that filters out escape sequences and such. All decent PHP applications do this before they ever make calls to a SQL database, for example.

This first case you mentioned is quite obvious: someone can destroy your system. Another one is if that you could be given a set of binary code that overwrites instructions/functions within your code, and has your program do something different entirely (ie: this is how jailbreak/root attacks work). For more information on this particular threat, you should read up on buffer overflow and code injection exploits: http://en.wikipedia.org/wiki/Code_injection

Also, there is an example of doing code injection here: Understanding and doing Code Injection in C

Upvotes: 2

geekosaur
geekosaur

Reputation: 61459

In general, "safe" is by comparison to the exec family of system calls (execve() being the lowest level standard one); involving a shell not only means problems with unsanitized data but also with $PATH (do you know what you are executing?) and with $IFS (this is a fun one: if someone can change $IFS on you, the shell won't parse things the way you expect).

Upvotes: 3

theglauber
theglauber

Reputation: 29665

It's impossible to know what "someone" had in mind, but perhaps it's because system() runs commands through the shell, which may result on the ultimate command execution being different from what you had planned. For example, you don't know what the PATH environment variable will be set to, as well as a miriad other changeable things.

Stick to the variations of exec, but even so, be very careful about what you pass to them.

Upvotes: 0

Related Questions