How well are Cocoa UI and general framework elements protected against malicious attacks?

Question

So far I had little concern about overall security considerations, because I have been developing only promotional and uncritical iPhone apps.

Currently, however, I'm working on a Mac application which requires a few more thougts about the matter, because it deals with sensitive user information.

While I know that I must take care to protect the data in its physical form (on disk), for example by encrypting it, I wonder how safe it is while it resides in memory in the course of normal use of the application.

Thus I'd like to know:
How safe is my application as long as it is built only upon framework elements such as NSTextField and Core Data?

How sensitive are Cocoa input elements to malicious attacks? What would be the best way to protect saved data which is stored using Core Data?

Calumet

Answer 1

Objective-C is a dynamic language, which means that it is possible to replace classes and specific methods of classes at runtime. For example, this is how the 1Password plugin finds its way into Safari, and Dropbox finds it way into the Finder. It is currently possible for a malicious attacker to use the low level mach_inject API, or a number of other slightly higher-level methods, such as SIMBL or OSAX injection, to load code into your app. Once code is loaded into your app, the dynamic nature of Objective-C makes it possible in theory to replace NSTextField with a subclass of the attacker's choice, or specific methods in the class, including listening and storing user input. The secure version of NSTextField, which is designed for passwords, may have some protections against this, though I haven't found specific documentation to that effect. Security.framework and the keychain APIs in general do have protection for your data in memory, and they are not based on Objective-C, so it is significantly harder (although maybe still possible) to interfere with them.

Waldron

There was an interesting (double) episode of Late Night Cocoa where the guest discusses "Hacking Cocoa". Though they're not discussing "security" exactly, it is an interesting look at code loading works on this platform: itunes.apple.com/us/podcast/late-night-cocoa/id213023580# – Compliance

Answer 2

To add to mgorbach's answer above (which is very good), Core Data can store data in four forms:

1. SQLite3 Database (most common)
2. .plist File (e.g. XML)
3. Binary File
4. In-Memory (non-persistent storage)

Neither .plist, Binary File, or SQLite are secure. .plist files can be easily read. A Binary file will be trickier, but AFAIK it's not using any encryption, and any Objective-C coder should easily be able to extract its contents. SQLite isn't secure either. Tools like SQLite Manager for FireFox, or Base for Mac, make it trivial to read Core Data SQLite data.

Since no Core Data storage methods are secure, your best bet is to encrypt data before committing it to disk.

This doesn't take into consideration any in-memory attacks. Of course, for this to be successful, a system typically has to already be compromised somehow.

If an end-user has FileVault enabled (encrypts their entire home folder), secure virtual memory enabled, their Firewall on, and a strong password, they're reasonably safe against many attacks.

Twoedged