Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
- Subject: Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
- From: Wade Tregaskis <email@hidden>
- Date: Mon, 01 Aug 2011 17:42:03 -0700
>>> Granted that NSKeyedUnarchiver might have left some memory leaks or partially uninitialized objects somewhere, but unarchiving an invalid object should happen rarely if at all... and ordinarily my own code should never get pointers to such objects, anyway.
>>
>> Indeed there may be memory leaks, but that's a relatively benign side effect. The security issues I alluded to earlier are a much greater concern in any case.
>
> Can you be more specific about those side effects? I'm rather curious,
> and somewhat concerned; I've used NSCoding in the past for persisting
> data.
[[ Sorry for the delay; I've had a busy weekend. ]]
Basically, because there's little validation built-in to NSUnarchiver. I'm going to talk about "attackers" here, but keep in mind that you can substitute "random corruption" and the points stand. So even without an "evil hacker" going after your app, you could still hit these issues.
So, some problems:
1) People typically do little validation of values they unarchive, so an attacker could substitute all sorts of things which might put the object into an unexpected state. While any individual developer could write their decoding carefully, I don't know if all of the standard Apple classes that they're likely using have similarly robust validation. Plus in practice it's sometimes tricky to do this validation, and it feels awkward because it can create a lot of redundant code within your object.
2) Because the archive can specify any class that supports NSCoding. While technically you can work around this, by subclassing NSKeyedUnarchiver and overriding something like -classForClassName:, and having it throw an exception for invalid class names, most people don't do this. And even that is preferable to the approach of checking the decoded object's class because it prevents any code of that object being run (i.e. the decodeWithCoder:), since that code might itself have side-effects.
Some people recommend using property lists instead, since those are more restricted while being relatively similar. They don't necessarily solve issue #1, but they are (as far as I know) immune to #2. You could alternatively consider signing the encoded data, if that's possible for your use case.
_______________________________________________
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