|
|
Re: No need to worry about instances
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 Ashes to ashes, clay to clay; If your enemies don't get you, your own folk may.
Re: No need to worry about instances
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.)
Re: No need to worry about instances
My mistake Vasantha, I typoed your name in the above post. My apologies. Thanks again. |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.05 seconds |
|