[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 9 Nov 2019 13:04:10 +0000
On Sat, Nov 9, 2019 at 12:38 PM Richard Frith-Macdonald
> > On 9 Nov 2019, at 11:40, Gregory Casamento <address@hidden> 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
> 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)
if you use decodeObjectOfClasses:forKey: and the set of Class objects
passed to 'decodeObjectOfClasses:' contains *both* the collection
and the classes of the objects which form the contents, it seems like
you can limit it to a specific set of 'subject' classes...