Tuesday, May 5, 2020 [Tweets] [Favorites]

Psychic Paper

Siguza (via Steve Troughton-Smith, Hacker News):

Yesterday Apple released iOS 13.5 beta 3 (seemingly renaming iOS 13.4.5 to 13.5 there), and that killed one of my bugs. It wasn’t just any bug though, it was the first 0day I had ever found. And it was probably also the best one. Not necessarily for how much it gives you, but certainly for how much I’ve used it for, and also for how ridiculously simple it is. So simple, in fact, that the PoC I tweeted out looks like an absolute joke. But it’s 100% real.

[…]

A very interesting thing about this bug is that I couldn’t point you at any particular piece of code and say “there’s my bug”. The reason for that is that, of course, iOS doesn’t have just one, or two, or even three plist parsers, it has at least four!

[…]

Because it’s very hard to parse XML correctly, valid XML makes all parsers return the same data, but slightly invalid XML makes them return just slightly not the same data. :D In other words, any parser difference can be exploited to make different parsers see different things. This is the very heart of this bug, making it not just a logic flaw, but a system-spanning design flaw.

[…]

This means that while IOKit considers <!---> as just the start of a comment, CF considers it as both start and end. After that, we feed both parsers the <!--> token, which is now too short to be interpreted as a full comment by either of them. However, the difference in states (in a comment vs. not in a comment) causes a very interesting behaviour: if we’re currently inside a comment, both parsers see the --> ending a comment, otherwise they both just see the <!-- starting one.

John Gruber (tweet):

So Siguza’s exploit — which granted an app full access to the entire file system, and more — uses malformed XML comments constructed in a way that one of iOS’s XML parsers sees its declaration of entitlements one way, and another XML parser sees it another way. The XML parser used to check whether an application should be allowed to launch doesn’t see the fishy entitlements because it thinks they’re inside a comment. The XML parser used to determine whether an already running application has permission to do things that require entitlements sees the fishy entitlements and grants permission.

Rob Hiller:

Implementing 4 different parsers is just asking for trouble, and the ‘fix’ is of the crappiest sort, bolting on more crap to check they’re doing the right thing in this single case. None of this is encouraging.

This reminds me of the time last year when I spent several months going back and forth with App Review and DTS because my app wouldn’t launch in the App Review environment, even though it worked fine for me. It turns out that, after uploading your submission, they post-process the entitlements plist, and that particular XML parser discards everything after the first comment. My app wouldn’t launch because the entitlements needed for the hardened runtime got stripped. This was apparently an old bug that got fixed and then came back.

1 Comment

[…] More commentary. Hacker News thread. […]

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment