Hm. I was specifically thinking of unrecognised selector exceptions, although I
might have came up with a much more dangerous scenario: recognised selectors.
What happens if the instantiated class *does* recognise the selector, but it
doesn't quite do what you think it does. Say, -open, or -unlock. How dangerous
is it to call such a selector on an instance of unknown type? Quite, I think.
And it might lead to exploits. I guess that it's not safe to assume that
without type checking the contained instances you'll be safe from exploits. But
definitely the most immediate threat is just crashing the app.
Cheers.
> Subject: Re: NSSecureCoding with containers (or, is NSArray lying?)
> From: graham....@bigpond.com
> Date: Fri, 17 Jul 2015 09:52:33 +1000
> CC: r...@rols.org; cocoa-dev@lists.apple.com
> To: andre.frate...@hotmail.com
>
>
> > On 16 Jul 2015, at 12:17 pm, André Francisco <andre.frate...@hotmail.com>
> > wrote:
> >
> > This can easily crash an app if I get a type that I'm not expecting, even
> > if it implements NSSecureCoding.
>
>
> Actually, probably not. It will likely start throwing exceptions all over the
> place, which *may* cause termination, but it won’t crash in a way that could
> lead to an exploit.
>
> —Graham
>
>
_______________________________________________
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
