3 ms·

The API for system() is not great, but the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals,

by agwa 12y ago

The API for system() is not great, but the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals, and waiting. As long as you're not passing arguments from outside sources to the command, using system() should be OK.

clarry 12y ago
And in some cases invoking the shell and letting it do its thing is expected, intended and desirable.
- wahern 12y ago
  Would you execute random Perl or Python code from the internet? No, you wouldn't, even if you tried to sanitize it a thousand ways from Sunday. So why would you do so for the shell? Defense must use different strategies than offense. An engineer's goal should be to reduce the problem space to something as small as possible, so he has a better chance at implementing a correct solution. Allowing the shell to be invoked is a good way to explode your exploitable surface area. Anybody who coded in the 1990s knows to stay away from the shell like the plague, even though the syntax parsing and evaluation components in modern shells have improved considerably. Sadly this particular bug harks back to the bad days, when it was more difficult to tell how certain constructs would be evaluated. It's not that you can't theoretically do it securely, it's just that you're gratuitously playing with fire--fire that has burned countless engineers in the past. The cost+benefit is so indisputably skewed toward little cost and huge risk that it's unprofessional to suggest otherwise. The shell shouldn't come anywhere near network-facing software, period.
asveikau 12y ago
> are not drop-in replacements since they don't take care of forking, changing the signals, and waiting. I never claimed it as a drop-in replacement. I think you know the solution to these problems. (I guess maybe someone who naively uses system() might not, so perhaps I need to work on a better spiel.) > As long as you're not passing arguments from outside sources to the command, using system() should be OK. Personally I've seen too many bad uses of system() to make that a thing. Maybe they'll not realize it's subject to PATH and that PATH can be untrusted. Maybe they'll not realize they sometimes have asterisks and spaces in a filename. And so forth...
__david__ 12y ago
> the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals, and waiting. Maybe not in C, but they are a drop-in replacement in just about every scripting language. Perl, Ruby, Python, all have nice high level calls that mostly mimic system() but use execve underneath—You simply pass system() multiple arguments instead of a single string. `system("")` in your production web app server code is almost certainly incorrect. Sadly I think PHP still doesn't have this. > As long as you're not passing arguments from outside sources to the command, using system() should be OK. Very true, but think about whether you really need a shell to launch your command (are you using any shell features?). If not, why not just launch the command directly?

by agwa 12y ago

clarry 12y ago

And in some cases invoking the shell and letting it do its thing is expected, intended and desirable.

wahern 12y ago
Would you execute random Perl or Python code from the internet? No, you wouldn't, even if you tried to sanitize it a thousand ways from Sunday. So why would you do so for the shell? Defense must use different strategies than offense. An engineer's goal should be to reduce the problem space to something as small as possible, so he has a better chance at implementing a correct solution. Allowing the shell to be invoked is a good way to explode your exploitable surface area. Anybody who coded in the 1990s knows to stay away from the shell like the plague, even though the syntax parsing and evaluation components in modern shells have improved considerably. Sadly this particular bug harks back to the bad days, when it was more difficult to tell how certain constructs would be evaluated. It's not that you can't theoretically do it securely, it's just that you're gratuitously playing with fire--fire that has burned countless engineers in the past. The cost+benefit is so indisputably skewed toward little cost and huge risk that it's unprofessional to suggest otherwise. The shell shouldn't come anywhere near network-facing software, period.

asveikau 12y ago

> are not drop-in replacements since they don't take care of forking, changing the signals, and waiting. I never claimed it as a drop-in replacement. I think you know the solution to these problems. (I guess maybe someone who naively uses system() might not, so perhaps I need to work on a better spiel.) > As long as you're not passing arguments from outside sources to the command, using system() should be OK. Personally I've seen too many bad uses of system() to make that a thing. Maybe they'll not realize it's subject to PATH and that PATH can be untrusted. Maybe they'll not realize they sometimes have asterisks and spaces in a filename. And so forth...

__david__ 12y ago

> the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals, and waiting. Maybe not in C, but they are a drop-in replacement in just about every scripting language. Perl, Ruby, Python, all have nice high level calls that mostly mimic system() but use execve underneath—You simply pass system() multiple arguments instead of a single string. `system("")` in your production web app server code is almost certainly incorrect. Sadly I think PHP still doesn't have this. > As long as you're not passing arguments from outside sources to the command, using system() should be OK. Very true, but think about whether you really need a shell to launch your command (are you using any shell features?). If not, why not just launch the command directly?