On 9 Dec 2009, at 10:02, jonat...@mugginsoft.com wrote:
> On 9 Dec 2009, at 09:53, Alastair Houghton wrote:
>>
>> It is possible to get the path to your executable using the dyld API, but
>> before doing such a thing you need to be very clear as to why you need it
>> and what it is that you're going to do with it. It's very easy to end up
>> with major security holes or just plain broken behaviour.
>>
> I have used the following in the past. Just curious to know what the holes
> and dodgy behaviour is likely to be.
>
> Dl_info info;
> int errDlAddr = dladdr( (const void *)__func__, &info );
> if(errDlAddr == 0) {
> return nil;
> }
> char *exec_path = (char *)(info.dli_fname);
>
> NSString *path = [NSString stringWithCString:exec_path
> encoding:NSUTF8StringEncoding];
Well it depends what you're going to do with it.
The classic example of a vulnerability due to code of this sort is that someone
with some kind of elevated privileges uses the path to execute their own
process again for some reason, but in the meantime some mischievous user has
managed to substitute another executable somehow. As a result, this other
executable gets launched with elevated privileges...
It might seem that this is unlikely to happen for e.g. setuid programs because
of the difficulty of replacing them, but it's quite common for these kinds of
APIs to return non-canonical pathnames so it's often possible to use symlinks
that *are* under your control and then change them immediately after launching
the child process.
dladdr() doesn't appear to say whether or not the filename it returns is
canonical, so I wouldn't be inclined to use it without calling realpath() on it
first, but even then it's best avoided.
So that's the security hole side of things. The other problem is, of course,
that someone could legitimately move, replace or even delete the file, which is
likely to break anything that relies on "knowing" its path.
IMO, the paths returned by the system are suitable for, at most, displaying to
the end user or putting into a crash log. Anything more than that is risky and
can lead to broken behaviour.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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 arch...@mail-archive.com
