Re: Delete myDriver.kext files from normal user.
Re: Delete myDriver.kext files from normal user.
- Subject: Re: Delete myDriver.kext files from normal user.
- From: "Clark Cox" <email@hidden>
- Date: Fri, 17 Oct 2008 18:13:38 -0700
On Fri, Oct 17, 2008 at 5:55 PM, Jonathon Kuo
<email@hidden> wrote:
>
> On Oct 17, 2008, at 5:33 PM, Michael Ash wrote:
>
>> On Fri, Oct 17, 2008 at 5:29 PM, Kyle Sluder
>> <email@hidden> wrote:
>>>
>>> On Fri, Oct 17, 2008 at 5:17 PM, Jonathon Kuo
>>> <email@hidden> 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@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden