Quarter Life Crisis

The world according to Sven-S. Porst

« iTunes ProblemsMainRoundup »


801 words

Pierre Igot has complained about his applications asking for permission to access his keychain after many system updates, even those that didn't update the application itself. My take at this was to say that for security reasons it may be a good idea to have the user confirm each access to the keychain by a modified application. And even if the applications themselves didn't change, changes to the libraries they use may compromise their integrity and furthermore those changes may cause the applications to change as well, thanks to prebinding.

So what is prebinding? I may not be the most competent person to report on this [check Google and Apple as well], but the main story seems to be the following: Applications use libraries of functions that programmers don't want to re-program every time – like QuickTime, say. To access particular functions within those libraries they have to know where to find them. One way to do that is to store the exact address of the function in the application. Doing so has the disadvantage that a change to library may cause all programs using it to break – you'll have to be careful to keep older versions of the libraries around.

Hence, people devised ways to access the functions by their names, which can be located in any version of the library. That, of course, will cost some extra processing time and can be slow when all the names have to be looked up. Assuming that libraries don't change too frequently, a trick is to store the addresses for the current version of the library in addition to the names. This will speed up access to those functions as long as the library doesn't change and still leaves the opportunity for the slow lookup should the version have changed. That's what I gather prebinding is.

As the addresses are actually stored in the application itself, the application will change if its prebinding changes, causing the slight annoyance Pierre, and ever other OSX user, sees.

While I guess this makes a rather secure design, it also raises a number of questions as to how secure this actually is and whether the inconvenience is worth the perceived increase in security.

Can a library change without the applications depending on it changing? If the whole prebinding thing really is as simple as I describe it above, this may be the case as a malevolent hacker could arrange for the numbers to remain the same. In that case, there is no extra security offered. (But I don't know how prebinding works internally, so I can't tell).

Was the keychain actually designed with this kind of security in mind? Who knows how applications are actually recognised by the keychain? I don't. Perhaps it only checks the executable's modification date or the file size. In those cases, the additional requests by the keychain after updates aren't there intentionally and just 'collateral damage' if you wish.

Does anyone pay attention to those questions by the keychain? As long as they originate from a known application, I'd say 'No'. Thus, even if you have a manipulated library on your computer or a virus hogging to one of your applications, you'll most likely click the 'Yeah, go access my keychain' button as you know that these dialogues come up more frequently than you think they should. Hence, no extra security is offered here.

This last problem should be even worse in lab situations where the system and applications are not maintained by the user. Thus, the user will be even less aware of the updates going on and won't see the correlation between them and the confirmations required by the keychain. In addition the user has no other chance than to trust his or her BOFH anyway. Finally, the annoyance this causes will be multiplied by the number of users on those systems.

All in all this is a tricky situation. I see the advantage of requiring user confirmation for access to the keychain. It's a good thing that applications I download and use can't simply e-mail my passwords around the world first thing after launching. On the other hand, it is completely unclear how far security is designed to go and how far it really goes technically. This lack of clarity along with the annoying number of confirmation dialogues will probably most of the extra security offered.

MacOS X.3 may at least address the problem with the user having to confirm every single password an application wants to access by offering an 'Allow this application to access all passwords' option. I can't offer a link for this, but I'm fairly sure that's what I saw on one of the rumor-mills. That may reduce user annoyance – but I'm not sure it will fully address the issues I mentioned above.

October 22, 2003, 1:06


Comment by Michael Tsai: User icon

How about if the prebinding information weren’t stored in the application binary?

October 22, 2003, 18:20

Comment by ssp: User icon

I agree that changing the binary seems a bit dodgy. Are there any real arguments for this being a bad thing?

As this seems to be done for performance the question is whether this wouldn’t jeopardise part of the gain.

And the system’d have to be quite elaborate I guess. Having Caches around just seems very messy. (But would be handy for write protected volumes, say.)

October 22, 2003, 22:01

Add your comment

« iTunes ProblemsMainRoundup »

Comments on




This page

Out & About

pinboard Links


Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.