On Fri, Oct 17, 2008 at 5:55 PM, Jonathon Kuo <[EMAIL PROTECTED]> wrote: > > On Oct 17, 2008, at 5:33 PM, Michael Ash wrote: > >> On Fri, Oct 17, 2008 at 5:29 PM, Kyle Sluder >> <[EMAIL PROTECTED]> wrote: >>> >>> On Fri, Oct 17, 2008 at 5:17 PM, Jonathon Kuo >>> <[EMAIL PROTECTED]> wrote: >>>> >>>> Just curious why the recommendation against system()? >>> >>> 1) There's no need for it here. Why launch /bin/sh just to launch >>> /bin/rm, when you can call unlink(2) yourself? >>> 2) In this case, system(3) will launch a shell *as root*. It's almost >>> always preferable to avoid this. >>> 3) Doing anything involving arguments is always a tricky subject, >>> because of Unicode. >>> 4) Invoking shells (through use of system(3) in particular) is >>> typically a red flag. It's usually indicative of a lack of knowledge >>> of the environment. >> >> And most important of all (I think), it almost always opens a security >> hole. >> >> This case is a great example. The system() call as posted uses "rm" as >> the command. This in turn relies on the $PATH to hand over the correct >> rm. It is probably feasible, maybe not even very hard, to ensure that >> this person's application gets launched with a custom-crafted $PATH. >> Make the first entry in $PATH be a special directory containing an >> executable script called "rm" that spawns a root shell and makes it >> listen on a certain TCP port and, bam, you've just been compromised. > > >> Certainly there are a lot of ways to write security vulnerabilities. >> But most of the time they happen because you make a mistake. System() >> is insecure *by default*, and takes special effort and attention to >> make it not be insecure. Much better is to simply not use it in the >> first place, as no good can possibly come of it. > > If the coder doesn't take care to use fully qualified pathnames like > /bin/rm, etc., then it opens the door to security issues. That's not an > inherent problem with system(), per se, but the coder.
It's a problem with system in that system invokes a shell (and all that entails; filename globbing,, variable expansion, searching the user's $PATH for executables, etc.) > Wouldn't fork()/exec() and NSTask also suffer from this same issue? Neither exec(), nor NSTask invoke a shell (unless, of course, you pass a shell as the executable). Because there is no shell (and no $PATH to search), the problem space with exec or NSTask is much smaller. -- Clark S. Cox III [EMAIL PROTECTED] _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
