The author mentions that this bug saved him 1000s of hours in development. How is a sandbox escape useful in development? Can someone give me an example?
Psychic Paper: iOS Sandbox Escape
11–20 of 61 posts
Re: Psychic Paper: iOS Sandbox Escape
#12The author mentions that this bug saved him 1000s of hours in development. How is a sandbox escape useful in development? Can someone give me an example?
If you're looking for 0day kernel exploits that might be popped from say MobileSafari, having an unrestricted, unsandboxed non-root shell is a much better starting point compared to a regular sandboxed app launched from xcode. Or even just for inspecting the filesystem outside a regular app's restricted container.
Re: Psychic Paper: iOS Sandbox Escape
#13This reminds me a lot of one of the original ways to run unsigned code on the Sony PSP.
If you made two directories:
SomeApp
SomeApp%
So all you need to do is get any binary with a valid sig and put it in the SomeApp folder while putting the code you actually want to run in SomeApp%.
Re: Psychic Paper: iOS Sandbox Escape
#14Once 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.
…in OS X 10.2? In 2002?[0]
Seems like a significant amount of time.
Re: Psychic Paper: iOS Sandbox Escape
#15Once 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.
…in OS X 10.2? In 2002?[0] Seems like a significant amount of time. [0]: https://en.wikipedia.org/wiki/Property_list#History
Property lists have been around since forever. They're NeXT technology.
Re: Psychic Paper: iOS Sandbox Escape
#16Maybe 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 agree in general. But XML as used in plists is actually not especially complicated, if you aren't trying to be a webbrowser and tolerate invalid input.
Your security-sensitive parser should not attempt to tolerate invalid input.
Probably you should not have multiple separate implementations of it, either.
Re: Psychic Paper: iOS Sandbox Escape
#17Once 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.
I thought the Windows Registry was reviled because it was a single database that held everything from user customization to device driver and boot configuration, in one file. It was contrasted with the Unix/Linux way, which was single-purpose text files, with the system-wide configuration in protected /etc files, and user-specific configuration in ~/. files
Plists are the best of both worlds. They're a file format rather than a system database, so user-specific config goes in ~/Library/, application-specific config goes in the *.app/ bundles, and system-wide config is in /System or /Library. But it's also a unified format, so each program doesn't need to implement its own parser, and users and developers don't have to wonder how application XYZ decided to escape backslashes, in its config file.
How are they "the macOS equivalent of windows registry"? Or is that just a generic techno-slur?
Re: Psychic Paper: iOS Sandbox Escape
#18Once 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.
It is far from the Windows registry. Everything is file-oriented, making it easy to backup or wipe away any given plist. The plists themselves are well named and located files that tell you what it is, and things don’t appear in multiple places. No program that gets installed needs to modify any system plists; in fact, apps pretty much never access plist that they don’t own. This last fact makes it so different from windows that you don’t see “plist repair apps” in the same way you do for windows.
Binary plists are identifiable to ascii plists, they’re just more compact. plutil is a utility that can convert them back and forth. Internally the plist classes can be passed either to load and they won’t bat an eye.
Re: Psychic Paper: iOS Sandbox Escape
#19Maybe 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!
Plists support dates (json doesn’t explicitly), and has you explicitly type the contents, which can help make sure that when you want a string you don’t get an int.
Re: Psychic Paper: iOS Sandbox Escape
#20Maybe 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.
So much has been rewritten you can’t really call it legacy at this point.