Psychic Paper: iOS Sandbox Escape(siguza.github.io) |
Psychic Paper: iOS Sandbox Escape(siguza.github.io) |
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%.
It's not just developer tools that suffer from this problem. I opened iMovie recently after not playing with it for almost 10 years, and was so flabbergasted at how everything worked. Took me almost 2 weeks to sync my own song to a series of cut video clips (cut out of larger videos, which was the main problem). Maybe I'm just an idiot, but googling around for solutions ended up with either out-of-date answers or completely unrelated problems.
I just wish that the app would use even one or two conventions from the 40-50 years of GUI research that has been done...
Drives user engagement too: people spend longer in your app (working out how the fuck to use it, again!).
An interface which lasts generations because its good is not the same, necessarily, as this years hot new ideology among the design elite.
If you live long enough, you see cycles repeat.
Try to compare the Android best practices across all IOs since Android exists.
The fact that Apple is maintaining multiple parsers, and apparently added yet another in response to this bug, just smells bad.
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?
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.
[0] https://duo.com/blog/duo-finds-saml-vulnerabilities-affectin...
-Apple should provide better audit tool so that security consultants don't need to rely on unpublished 0day exploits to find other exploits
-As an exposed user I really don't thank grey hat People that refrain from publishing 0day exploit for two frigging years for personal gain...
> An XML parser, for the purposes of this specification, is a construct that follows the rules given in XML to map a string of bytes or characters into a Document object.
> Note: At the time of writing, no such rules actually exist.
What do the authors of HTML mean by this? Isn't there a spec for XML? There is -- here's what it has to say about comments (https://www.w3.org/TR/xml/#sec-comments):
Comment ::= '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'
12.2.5.45 Comment state
Consume the next input character:
U+003C LESS-THAN SIGN (<)
Append the current input character to
the comment token's data. Switch to
the comment less-than sign state.
U+002D HYPHEN-MINUS (-)
Switch to the comment end dash state.
U+0000 NULL
This is an unexpected-null-character
parse error. Append a
U+FFFD REPLACEMENT CHARACTER
character to the comment token's data.
EOF
This is an eof-in-comment parse error.
Emit the comment token. Emit an end-
of-file token.
Anything else
Append the current input character to
the comment token's data.
You can see the success of this approach on the real web; inconsistent HTML parsing between browsers is no longer the issue it used to be 15 years ago. It may be more work to write, but I wish HTML's precise, step-by-step format was more common. Writing a spec as a list of rules makes it easier to implement (as a first pass, you can just go line-by-line and translate it to code) and reduces the chance of inconsistencies like the one in the article (and their associated security implications).
Your security-sensitive parser should not attempt to tolerate invalid input.
Probably you should not have multiple separate implementations of it, either.
By the time stuff like JSON started popping up, plists were pervasive all throughout OS X. Typical legacy problem!
https://developer.apple.com/library/archive/documentation/Co...
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.
[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
IOS was released last week by mental accounting standards.
To hear both be branded as ‘legacy’ is, frankly... well, it makes me feel ancient.
Does cfprefsd react well to that these days?
The declarative form of Comment, above, is wonderfully concise and clear when compared to these several lines of imperative, update-this/goto-there style alternative. You can see in your head what it should match without mentally simulating these specific instructions against some imagined parser state.
There certainly can be a host of terrible issues with BNF-style grammars. When they're just used as a notation to write down a bunch of rules, with no regard to actually implementing these rules, the result can be a sprawling and terribly ambiguous mess. For instance, this[1] is an abject disaster, chock full of ambiguity and senseless distinctions.
But if one is prepared to take the effort to really write a machine-readable grammar like this[2], the result is a straightforward, high-level, concise spec that can be compiled into an implementation to boot. What's not to like?
[1] http://sven.xtreme-eda.com/ [2] https://docs.python.org/3/reference/grammar.html