Re: NSSecureCoding....

[Richard Frith-Macdonald]

> On 9 Nov 2019, at 13:04, Matt Rice <ratmice@gmail.com> wrote:
> 
> On Sat, Nov 9, 2019 at 12:38 PM Richard Frith-Macdonald
> <richard@frithmacdonald.me.uk> wrote:
>> 
>> 
>> 
>>> On 9 Nov 2019, at 11:40, Gregory Casamento <greg.casamento@gmail.com> wrote:
>>> 
>>> Does anyone have any clue how we are going to tackle NSSecureCoding?
>> 
>> I don't really understand it.
>> 
>> The basic principle of it is simple: make hacking of archives by an attacker 
>> harder by preventing the attacker from substituting different classes into 
>> the archive.
>> 
>> This uses a new -decodeObjectOfClass:forKey: method to decode objects of a 
>> specific class (easy to implement), plus a trivial method/property 
>> -supportsSecureCoding  to say whether a class does secure coding or not.
>> 
>> So the alterations are simple, but extensive and time consuming to implement 
>> (we'd need to retrofit/add this to decoding of most classes).
>> 
>> My problem with it is that it's hard to see how it can work when it comes to 
>> collections ... yet the Apple documentation says that (for instance) NSSet 
>> supports secure coding.
>> That should mean that an NSSet decodes its contents with 
>> -decodeObjectOfClass:forKey: specifying the class of each object the set 
>> holds.
>> However, a set holds arbitrary values (any class), so presumably it would 
>> have to decode its contents using NSObject as the class, effectively that's 
>> the same as using -decodeObjectForKey: and allows unconstrained alteration 
>> of the set contents by an attacker, defeating the whole point of secure 
>> coding.  It suggests to me that having arbitrary collection classes claim to 
>> implement NSSecureCoding would be misleading/wrong.
>> 
>> So presumably I'm missing/misunderstanding something about this.
> 
> Weird problem, but interesting I suppose,
> It looks like (according to this stack overflow)
> https://stackoverflow.com/questions/24376746/nssecurecoding-trouble-with-collections-of-custom-class
> 
> if you use decodeObjectOfClasses:forKey: and the set of Class objects
> passed to 'decodeObjectOfClasses:' contains *both* the collection
> class,
> and the classes of the objects which form the contents, it seems like
> you can limit it to a specific set of 'subject' classes...

Interesting.  I had missed seeing that method.  But it does look like that's 
how they intend it to work.

It seems a badly designed API to me (I'd have gone with something like 
-decodeContainerOfClass:withContentsOfClasses:forKey:).

I guess we'd need to reverse-engineer how it actually works. The immediate 
question for me is that, if the set of classes contains the class of the 
container, does that mean that the contents may also be of the same class as 
the container, or does it mean that the contents may be of any of the classes 
in the set apart from that of the container?
If the former, then you can't (for instance) securely decode an array of 
strings, because the array might contain arrays.
If the latter, then you can't decode an array containing both strings and 
arrays.