3 ms·
It's striking how often these PZ iOS exploits at some point come around to too-polymorphic use of object unarchiving. Other examples: https://googleprojectzer
by valleyer 5y ago
It's striking how often these PZ iOS exploits at some point come around to too-polymorphic use of object unarchiving. Other examples:
https://googleprojectzero.blogspot.com/2020/01/remote-iphone-exploitation-part-1.html https://googleprojectzero.blogspot.com/2020/01/remote-iphone...
https://googleprojectzero.blogspot.com/2019/08/the-many-possibilities-of-cve-2019-8646.html https://googleprojectzero.blogspot.com/2019/08/the-many-poss...
- londons_explore 5y agoIt would seem the solution is to require every 'unarchive' operation to provide a 'schema' which specifies exactly which classes will be used in the unarchive operation. That schema would be read-only and specific to the unarchive call site.
- valleyer 5y agoYou're sort of describing NSSecureCoding. Unfortunately, it's not used everywhere, and (because Cocoa relies heavily on internal class clusters) it still allows subclasses of the specified class.
- olliej 5y agoI also recall one exploit that happened despite using nssecurecoding because a special internal class was a subclass of a secure coding class