Re: Finding process path from Cocoa?
Re: Finding process path from Cocoa?
On 9 Dec 2009, at 10:18, Alastair Houghton wrote:
> On 9 Dec 2009, at 10:02, email@hidden 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 (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