Psychic Paper: iOS Sandbox Escape
siguza.github.io
Psychic Paper: iOS Sandbox Escape
1–10 of 61 posts
Re: Psychic Paper: iOS Sandbox Escape
#2XML is hard. Love that the fix is reminiscent of XKCD 927[1]
Re: Psychic Paper: iOS Sandbox Escape
#3Maybe we should take this as a lesson that we should use the simplest marshalling format that adequately captures our use cases rather than using a swiss-army knife format like XML.
Re: Psychic Paper: iOS Sandbox Escape
#4Once binary plists were introduced, it was only a matter of time before it became the macOS equivalent of windows registry.
The fact that Apple is maintaining multiple parsers, and apparently added yet another in response to this bug, just smells bad.
Re: Psychic Paper: iOS Sandbox Escape
#5Maybe we should take this as a lesson that we should use the simplest marshalling format that adequately captures our use cases rather than using a swiss-army knife format like XML.
Problem is legacy software tends to use XML. iOS can be considered legacy at this point. Plists are prevalent at every level of iOS.
Re: Psychic Paper: iOS Sandbox Escape
#6Maybe we should take this as a lesson that we should use the simplest marshalling format that adequately captures our use cases rather than using a swiss-army knife format like XML.
I’m not sure that there were much better choices available at the time. IIRC property lists date back to NextStep.
By the time stuff like JSON started popping up, plists were pervasive all throughout OS X. Typical legacy problem!
Re: Psychic Paper: iOS Sandbox Escape
#7Reminds me a bit of the CVE about SAML authentication being screwed up by bad XML parsers. Seems like a lot of low hanging fruit there still.
[0] https://duo.com/blog/duo-finds-saml-vulnerabilities-affectin...
Re: Psychic Paper: iOS Sandbox Escape
#8Maybe we should take this as a lesson that we should use the simplest marshalling format that adequately captures our use cases rather than using a swiss-army knife format like XML.
They could always drop XML for YAML and get more issues!
I dislike XML and would not chose it for my projects. But... in this case, it does seem like a good idea to require explicitly closed tags. Seems like it could remove 1000 error potentials for every 1 parser error.
Re: Psychic Paper: iOS Sandbox Escape
#9Maybe we should take this as a lesson that we should use the simplest marshalling format that adequately captures our use cases rather than using a swiss-army knife format like XML.
They could always drop XML for YAML and get more issues! I dislike XML and would not chose it for my projects. But... in this case, it does seem like a good idea to require explicitly closed tags. Seems like it could remove 1000 error potentials for every 1 parser error.
Yeah, an XML parser that allows invalid XML (tags must be closed, per the spec[1]) is pretty clearly a terrible choice for a security-sensitive purpose. Likely it was just oversight / accidental reuse, and it's a somewhat common error, but it's very much an engineering mistake and not an XML flaw.
[1] It's very clearly stated as item 2, in a 2-item list for well-formed-ness of documents: https://www.w3.org/TR/xml/#sec-well-formed
Re: Psychic Paper: iOS Sandbox Escape
#10Maybe we should take this as a lesson that we should use the simplest marshalling format that adequately captures our use cases rather than using a swiss-army knife format like XML.
Problem is legacy software tends to use XML. iOS can be considered legacy at this point. Plists are prevalent at every level of iOS.
As somebody who was already a high school student deeply ‘into’ computer technology at the time, I perfectly remember the hype and release of XML.
IOS was released last week by mental accounting standards.
To hear both be branded as ‘legacy’ is, frankly... well, it makes me feel ancient.