This reminds me a lot of one of the original ways to run unsigned code on the Sony PSP.<p>If you made two directories:<p><pre><code> SomeApp
SomeApp%
</code></pre>
And then launch the folder with the % sign then the code that checks for valid signatures will check in the directory without the %, but the code that actually launches the binary will still run the code in the directory with the %.<p>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%.
A while back I filed a bug on libplist with some examples of the hilarious this-is-not-XML issues in Apple's userland plist parser, which people might find fun here as it is highly related to this issue.<p><a href="https://github.com/libimobiledevice/libplist/issues/83" rel="nofollow">https://github.com/libimobiledevice/libplist/issues/83</a>
> I just hate GUIs for development, especially when you Google how to do something, and the answer is a series of 17 “click here and there”s that are no longer valid because all the GUI stuff moved somewhere else in the last update.<p>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.<p>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...
Maybe 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.
Once binary plists were introduced, it was only a matter of time before it became the macOS equivalent of windows registry.<p>The fact that Apple is maintaining multiple parsers, and apparently added yet another in response to this bug, just smells bad.
Reminds 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.<p>[0] <a href="https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations" rel="nofollow">https://duo.com/blog/duo-finds-saml-vulnerabilities-affectin...</a>
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?
I'm not in the security community and as an end user there seems to be two lesson there:<p>-Apple should provide better audit tool so that security consultants don't need to rely on unpublished 0day exploits to find other exploits<p>-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...
The section of the WHATWG HTML spec about parsing XHTML begins with this note:<p><i>> 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.</i><p><i>> Note: At the time of writing, no such rules actually exist.</i><p>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 (<a href="https://www.w3.org/TR/xml/#sec-comments" rel="nofollow">https://www.w3.org/TR/xml/#sec-comments</a>):<p><pre><code> Comment ::= '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'
</code></pre>
The HTML spec, on the other hand, writes out the token state machine explicitly. There are ten states involved with parsing comments; here's one (<a href="https://html.spec.whatwg.org/multipage/parsing.html#comment-state" rel="nofollow">https://html.spec.whatwg.org/multipage/parsing.html#comment-...</a>):<p><pre><code> 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.
</code></pre>
The spec defines what to do for every character, even characters that should not appear in valid HTML. An HTML parser will behave exactly the same as another HTML parser in all circumstances.<p>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).
XML is hard. Love that the fix is reminiscent of XKCD 927[1]<p>[1]<a href="https://xkcd.com/927/" rel="nofollow">https://xkcd.com/927/</a>