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: Jonathon Kuo <email@hidden>
- Date: Fri, 17 Oct 2008 17:55:55 -0700
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. Wouldn't fork()/
exec() and NSTask also suffer from this same issue?
_______________________________________________
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