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]

Reply via email to