Re: NSSecureCoding & NSAttributedString

2018-02-18 Thread Gary L. Wade 
FYI, you can define your own attributes using your own keys and values not 
defined by the frameworks, and the frameworks will ignore them from the 
standpoint of drawing. In one app, I used an attribute to add a time stamp to a 
run of text and overrode the glyph drawing so that when my code saw that 
attribute, it would draw an appropriate border around the entire run. I didn’t 
have a need to send that attributed string to other apps, but if I did, I would 
hope my custom attributes would be preserved round-trip provided the run was 
preserved.
--
Gary L. Wade
http://www.garywade.com/

> On Feb 18, 2018, at 2:26 PM, Quincey Morris 
>  wrote:
> 
> I dunno. I always though of the attributes as something extensible, but I 
> guess they’re not really. (They can’t be, in NSAttributedString is an 
> interchange format between apps.) Looking at the documented list, I would be 
> worried about NSTextAttachment, which isn’t even documented as conforming to 
> NSSecureCoding. Those NSAccessibility… keys don’t look too safe either.

___

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

Re: NSSecureCoding & NSAttributedString

2018-02-18 Thread Quincey Morris 
On Feb 18, 2018, at 14:27 , Markus Spoettl  wrote:
> 
> yet this works (don't know why)

I did this in Swift (so I could use a playground):

> print (NSTextTab.self.conforms (to: NSSecureCoding.self)) // true
> print (NSTextList.self.conforms (to: NSSecureCoding.self)) // true
> print (NSShadow.self.conforms (to: NSSecureCoding.self)) // false

___

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

Re: NSSecureCoding & NSAttributedString

2018-02-18 Thread Markus Spoettl 

On 2/18/18 23:01, Markus Spoettl wrote:

As for additional NSAttributeString "companion" classes, I'm still open for 
suggestions.


Sure enough I found other pulprits: NSTextList and NSShadow.

According to the header, NSTextList does not conform to NSSecureCoding, yet this works 
(don't know why). However the decoder stops playing nice with NSShadow, which also 
doesn't conform to NSSecureCoding.


For testing I copy/pasted complex web pages from the browser into my text field and tried 
loading that. First from Firefox (which brought in NSTextList) then from Safari which 
added NSShadow.


I'm sure there are other problem cases still hiding but given that it's so easy to produce 
an NSAttributedString that will blow up on loading I can bury any hope this will work 
eventually. Ever.


Thanks for listening :)

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

Re: NSSecureCoding & NSAttributedString

2018-02-18 Thread Quincey Morris 
On Feb 18, 2018, at 14:01 , Markus Spoettl  wrote:
> 
> 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.

Arrays aren't safe from structural attacks, I think. There’s no way of 
expressing an array of *only* some element class — an actual element that is an 
array of the stated element class will pass the global check.

> As for additional NSAttributeString "companion" classes, I'm still open for 
> suggestions.

I dunno. I always though of the attributes as something extensible, but I guess 
they’re not really. (They can’t be, in NSAttributedString is an interchange 
format between apps.) Looking at the documented list, I would be worried about 
NSTextAttachment, which isn’t even documented as conforming to NSSecureCoding. 
Those NSAccessibility… keys don’t look too safe either.

At this point, though, I don’t trust myself to reason about what’s safe and 
what’s not.

___

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

Re: NSSecureCoding & NSAttributedString

2018-02-18 Thread Markus Spoettl 

On 2/18/18 22:02, Quincey Morris wrote:
On Feb 18, 2018, at 10:30 , Markus Spoettl > 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

Re: NSSecureCoding & NSAttributedString

2018-02-18 Thread Quincey Morris 
On Feb 18, 2018, at 10:30 , Markus Spoettl  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.

___

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

Re: NSSecureCoding & NSAttributedString

2018-02-18 Thread Markus Spoettl 

On 2/18/18 06:12, Quincey Morris wrote:

On Feb 17, 2018, at 20:34 , Glenn L. Austin  wrote:


Or encode/decode them using Coding, then encode/decode the resulting encoded
attributed string data using SecureCoding.


Markus already said that archives exist with normally-encoded attributed 
strings, so
that precludes changing the archive format in the way you say.

But that does suggest a partial alternative. In the object that decodes the 
attributed
string, Markus can turn “usesSecureCoding” off for that decode only (in the 
coder
object, which has this property defined). This won’t be secure against attacks 
via the
objects *in* the attributed strings, but it would protect the rest of the 
archive.


As a security precaution Turning off requiresSecureCoding once it is turned on causes an 
exception, so that's not an option.


I have now gotten it to work simply by decoding the attributed string like this:

NSSet *allowed =
   [NSSet setWithObjects:[NSAttributedString class], [NSTextTab class], nil];
notes = [[decoder decodeObjectForClasses:allowed] retain];

The decoder isn't terribly concerned with where the individual classes will occur, just 
that they might.


Of course that doesn't mean that it will work generally speaking, just for my special 
case. I don't mind adding more allowed classes there, any ideas what else I (or rather my 
users) might encounter?


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