Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'Re: No need to worry about instances' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Re: No need to worry about instances
Authored by: Anonymous on Feb 07, '01 11:55:32AM

This could be my mistake then. So are you saying that if you build a static palette with a new object running a new thread, and then in IB you place that object in the interface, you would have to have a framework containing the object code? And that framework library would have to be passed along together with the nib? I was under the impression that static palette objects contained compiled code. I haven't been able to test that, because I am still trying to find some info on how to get the ProgressView example palette built, and how to use it in an app. I think static palettes are one of the best features of IB if I can find out how to create them properly.

Again my mistake and I retract the warning if what you say is true. I'm still planning on being careful until I find out more about how static palettes work in IB. Thanks for responding.

[ Reply to This | # ]
Re: No need to worry about instances
Authored by: _merlin on Feb 07, '01 10:41:47PM

The only classes you can instantiate are those in frameworks that the application links to, or in the application itself. A static palette is a class in the Application Kit framework, which all Cocoa applications link to, so you can instantiate it in any application. However if you wanted a static palette that was capable of malicious behaviour, the malicious code would have to come from somewhere. This would have to come from a framework, or be compiled into the application.

The purpose of a nib is to define characteristics of objects, and build links between them. You should not think of it as a way to build an application, as Visual Basic or Delphi is. I would still be careful about what nibs I use, as you can do some weird stuff with Interface Builder, but unless an application is already capable of destroying data, a nib, on its own, can't add this capability.

As I said before, if an application can already delete files (like the Desktop/Finder can), a nib may be able to use this capability for malicious purposes. I should point out that a lot of applications can indirectly delete files by saving over the top of them. You could make a malicious nib for some applications that causes them to save files over the top of other files without the user's knowledge. I experimentally confirmed that you can make malicious nibs that target specific files using this technique (shell history, preference files, etc.; system files are safe unless the application runs as root). Note that this requires the author of the nib to know the exact path and name of the file relative to your home directory, and the only application it worked on was one which I intentionally built this vulnerability into (I have no intention of releasing it).

It is impossible to make nibs that extract your passwords or copy sensitive data. These operations are far too involved for the simple linking you can perform in Interface Builder.

In conclusion, don't just install any nib you get your hands on. Always check it out in IB to make sure it looks sensible. You can make nibs that cause all kinds of strange behaviour, even if they do no real damage. However, there is no need to be paranoid about the damage nibs may do. The probability of an application being capable of causing damage through the use of malicious nibs is very low.

Vasantha Crabb
Professional Audio Services

Ashes to ashes, clay to clay; If your enemies don't get you, your own folk may.

[ Reply to This | # ]
Re: No need to worry about instances
Authored by: Anonymous on Feb 07, '01 11:08:18PM

Thanks, Varantha. I went back to "Discovering OpenStep" and also pieced together bits and pieces from the OmniGroup mailing list archives, and discovered how grossly mistaken I was. I have come to the conclusion that since the nib indeed only stores references to code that the program has access to, then it requires that cooperation from the application already be built in. (Noted that it doesn't store the code itself... just the instance variable state and a reference to the executable code... even less for custom classes. This is all much safer than I had thought from a security standpoint. I was being paranoid due to a misconception.)

It seems that it could reference code in another bundle, but the app would have to cooperate by loading the bundle for you.

I was just going to post the explanation, but you just posted, and your last post explains much more knowledgably than I could.

So my warning was bogus, and someone can post modified nibfiles for loginwindow and other apps that alter image size and text styles with no cause for concern. Much easier for most people. Thanks for setting me straight, and I have learned some helpful info for some projects I was thinking of working on. MMMMM.... tasty crow!

[ Reply to This | # ]
Re: No need to worry about instances
Authored by: Anonymous on Feb 07, '01 11:16:05PM

My mistake Vasantha, I typoed your name in the above post. My apologies. Thanks again.

[ Reply to This | # ]