5 ms·

It has been proven to be a weak point in their implementation with previous exploits, and it's likely to be the case here - it's a good guess at least. Will be

• saagarjha 6y ago
  Apple has been hardening their software to use NSSecureCoding and similar since then, so I would be surprised if this would still be a problem (since this is fairly easy to check for and fix). My guess is that this is probably a run-of-the-mill overflow or corruption.
  • amluto 6y ago
    That’s like saying one can harden pickle by specifying magic options and trying to limit the supported classes to a very large list instead of an effectively infinite list. Sure, you can make the the blatantly insecure mechanism harder to exploit, but it’s still a horrible design. I think Apple could address this for real is one of two ways. They could replace the protocol entirely, or they could treat the existing baroque protocol like any other network protocol and write a grammar and parser for it. As an analogy, suppose you had a wire format like XML, and you had the clever idea to process it in a dynamic language like Python or ObjC by looking up each tag in a list of all known types and trying to instantiate it. Sure, it would work, and you would be exploited all the time. NSSecureCoding limits the available types to a large and apparently still open ended list instead of literally every type that the deserializer can make sense of.