On 2/18/18 22:02, Quincey Morris wrote:
On Feb 18, 2018, at 10:30 , Markus Spoettl <ms_li...@shiftoption.com
<mailto:ms_li...@shiftoption.com>> wrote:
The decoder isn't terribly concerned with where the individual classes will occur, just
that they might.
I was going to reply that it’s stupid that it behaves like this, but I guess it makes some
sense after all. The secure coding protection against class substitutions can be global
like this, since class identities are global in the archive.
Still, you should probably assert “[notes isKindOf: [NSAttributedString class]]”
immediately after that decode. Maybe I’m overthinking it, but I’d worry that your
workaround enables some other kind of attack. For example, without the check, a
maliciously-crafted archive that cause “notes” to be a NSTextTab could potentially crash
your app, and that in turn might open up a vulnerability.
Yes, I have an NSCoder extension that does exactly that. You also need to consider
collections and dictionaries especially. Arrays are easy to enforce but dictionaries are
really a weak spot. For starters you can't define which classes are acceptable as keys
and which as values. What if you have collection classes as values, what layout is
acceptable in sub-entries? None of that is expressible.
I can appreciate the technical challenge retro-fitting secure coding into the existing
architecture, but what it is right now sure feels like an absolutely bare minimum approach.
As for additional NSAttributeString "companion" classes, I'm still open for
suggestions.
Best Regards
Markus
--
__________________________________________
Markus Spoettl
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
