Re: NSSecureCoding & NSAttributedString

[Markus Spoettl]

On 2/18/18 23:26, 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.


I'm not sure where the NSAccessibility… keys are defined, I looked at NSAttributedString.h 
they are not there. Anyway...


The saga isn't over yet, I found a workaround for the problem for classes that are not 
NSSecureCoding compliant:


First I sub-class the offending class, implementing the NSSecureCoding protocol, 
+supportsSecureCoding and -initWithCoder:. Since it is impossible to safely invoke the 
non-secure -initWithCoder: version of the class itself, I use a suitable other designated 
initializer when calling super.


Then I set up the class as substitution for the original in the NSKeyedUnarchiver using 
-setClass:forClassName:.


Finally I add it to the list of acceptable classes when decoding the attributed 
string.

Works fine for NSShadow, NSTextAttachment and NSCursor.

Of course this looses the attributes real values, but those I don't care about 
anyway.

I haven't encountered a cursor attribute yet, though.

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

[Quincey Morris]

On Feb 19, 2018, at 01:42 , Markus Spoettl  wrote:
> 
> I'm not sure where the NSAccessibility… keys are defined


https://developer.apple.com/documentation/foundation/nsattributedstringkey

> I found a workaround for the problem for classes that are not NSSecureCoding 
> compliant:
> 
> First I sub-class the offending class, implementing the NSSecureCoding 
> protocol, […].
> 
> Then I set up the class as substitution for the original in the 
> NSKeyedUnarchiver using -setClass:forClassName:.

Yikes! So you hack the unarchiving process to substitute a malfunction class 
for the real one, in order to protect the unarchiving process from being 
hacked? Is this really safer than not using secure coding at all? (That’s a 
genuine question. Maybe this *does* plug the hole.)
___

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

[Markus Spoettl]

On 2/19/18 18:56, Quincey Morris wrote:
On Feb 19, 2018, at 01:42 , Markus Spoettl > wrote:


I'm not sure where the NSAccessibility… keys are defined


https://developer.apple.com/documentation/foundation/nsattributedstringkey


I found a workaround for the problem for classes that are not NSSecureCoding 
compliant:

First I sub-class the offending class, implementing the NSSecureCoding 
protocol, […].

Then I set up the class as substitution for the original in the NSKeyedUnarchiver using 
-setClass:forClassName:.


Yikes! So you hack the unarchiving process to substitute a malfunction class for the real 
one, in order to protect the unarchiving process from being hacked? Is this really safer 
than not using secure coding at all? (That’s a genuine question. Maybe this *does* plug 
the hole.)


Yikes? Not really! IMHO it's actually elegant and uses only mechanisms that are available 
publicly and for the exact purpose of replacing classes. I just provide a "better" version 
of the classes that don't conform to NSSecureCoding which can be use as an stand-in in a 
safe way. The sub-classes conform to everything the base classes do + secure coding, so 
the NSAttributedString will be intact.


I don't think THAT is the problem with the approach. It's the uncertainty that I catch all 
cases that will be thrown at me. Given the extensive list of NSAccessibility.. keys many 
of which use (id) as value, the risk is high that it will blow up.


So, while not complete, I think that's an elegant fix, but unusable nonetheless.

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

[Quincey Morris]

On Feb 19, 2018, at 10:32 , Markus Spoettl  wrote:
> 
> for the exact purpose of replacing classes

Well, it’s not a cuckoo’s egg attack if the secure decoder is looking for the 
replacement cuckoo class, I guess. What still worries me is that you substitute 
with a class that doesn’t have the expected behavior *in context* (you: "Of 
course this loses the attribute's real values”).

However, as I said before, I’m not very good about reasoning out security 
threats, and so tend to be over-suspicious of creative solutions.

___

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