On 9 Dec 2009, at 10:18, Alastair Houghton wrote:
> 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.
>
In the above example we extract the path to the current process so I am not
sure if the above concerns would apply.
It could be argued that actively utilising any path to launch another process
is a security hole.
If your app loads an auxiliary executable from the main bundle then a user with
admin rights can intervene and modify the target.
Even code signing isn't invincible here. You could check, via codesign(1), for
the presence of your identifier.
But it's feasible to resign with a different identifier and patch the caller to
check for the modified id.
Regards
Jonathan
> 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
