• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSSecureCoding & NSAttributedString
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSecureCoding & NSAttributedString


  • Subject: Re: NSSecureCoding & NSAttributedString
  • From: Markus Spoettl <email@hidden>
  • Date: Sun, 18 Feb 2018 23:01:31 +0100

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

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:

This email sent to email@hidden

  • Follow-Ups:
    • Re: NSSecureCoding & NSAttributedString
      • From: Markus Spoettl <email@hidden>
    • Re: NSSecureCoding & NSAttributedString
      • From: Quincey Morris <email@hidden>
References: 
 >NSSecureCoding & NSAttributedString (From: Markus Spoettl <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Quincey Morris <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Markus Spoettl <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Alex Zavatone <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: "Glenn L. Austin" <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Quincey Morris <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Markus Spoettl <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: NSSecureCoding & NSAttributedString
  • Next by Date: Re: NSSecureCoding & NSAttributedString
  • Previous by thread: Re: NSSecureCoding & NSAttributedString
  • Next by thread: Re: NSSecureCoding & NSAttributedString
  • Index(es):
    • Date
    • Thread