Re: NSSecureCoding....
> Am 09.11.2019 um 13:39 schrieb Richard Frith-Macdonald > : > > > >> On 9 Nov 2019, at 11:40, Gregory Casamento 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. I think you are misled by the term “secure” here. As far as I understand the (limited) documentation, all that “secure coding” attempts to achieve is that it gives you some added type safety, so that, for instance, if you encode a NSWindow on one side, send it across the wire, and then attempt to decode it as, say, an NSView on the other side you’ll get an error rather than some garbage. It doesn’t look like it is an attempt to prevent attacks on the contents of an archive, which presumably would be better addressed at the level of the archive as a whole (for instance by adding a cryptographic signature to the archive) than at the level of individual objects. With that in mind, collection classes can trivially support secure coding because (ignoring generics) they do not make any constraints on their elements, so your code has to (or at least should) deal with arbitrary objects here anyway. Wolfgang
Re: NSSecureCoding....
> On 9 Nov 2019, at 13:04, Matt Rice wrote: > > On Sat, Nov 9, 2019 at 12:38 PM Richard Frith-Macdonald > wrote: >> >> >> >>> On 9 Nov 2019, at 11:40, Gregory Casamento 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.
Re: NSSecureCoding....
On Sat, Nov 9, 2019 at 12:38 PM Richard Frith-Macdonald wrote: > > > > > On 9 Nov 2019, at 11:40, Gregory Casamento 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...
Re: NSSecureCoding....
> On 9 Nov 2019, at 11:40, Gregory Casamento 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.
NSSecureCoding....
Does anyone have any clue how we are going to tackle NSSecureCoding? -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com http://ind.ie/phoenix/ [image: Mailtrack] <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;> Sender notified by Mailtrack <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;> 11/09/19, 06:39:34 AM
