iOS XML Bug

This is a good explanation of an iOS bug that allowed someone to break out of the application sandbox. A summary:

What a crazy bug, and Siguza’s explanation is very cogent. Basically, it comes down to this:

  • XML is terrible.
  • iOS uses XML for Plists, and Plists are used everywhere in iOS (and MacOS).
  • iOS’s sandboxing system depends upon three different XML parsers, which interpret slightly invalid XML input in slightly different ways.

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.

This is fixed in the new iOS release, 13.5 beta 3.

Comment:

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.

More commentary. Hacker News thread.

Tags: , , ,

Posted on May 7, 2020 at 9:56 AM • 19 Comments

Comments

flasker • May 7, 2020 12:51 PM

Interesting that this was sat on for 3 years, I wonder how many others are out there? It sure does seem possible that this specific research was able to find more vulnerabilities during those 3 years.

SwashbucklingCowboy • May 7, 2020 2:50 PM

Four different XML parsers is to be expected in world where half of what’s there is open source. One project used one parser, another project used a different parser, etc.

tfb • May 7, 2020 3:24 PM

The whole point of XML was that unambiguous parses were easy and it would be a stable standard. And much though I hate XML they succeeded: the current XML standard is still 1.0 and it’s getting on for 12 years old (younger than iOS, but not by much). So, you know, in 12 years Apple could have sorted out a parser that worked, you’d think. But no: they have at least three, none of which work.

And before someone snipes at Apple: it’s not just them. How many differently-buggy XML parsers are on whatever computer you use? Almost certainly dozens.

Wipe it away, please, wipe it all away.

Wael • May 7, 2020 5:28 PM

iOS’s sandboxing system depends upon three different XML parsers,

Three different parsers → three distinct VPs

Lawrence D’Oliveiro • May 7, 2020 5:52 PM

Conway’s Law comes to mind: “any piece of software reflects the organizational structure that produced it”. 3 different XML parsers sounds like 3 different groups working on those parts of the OS, while the addition of a fourth to block the hole suggests that nobody with any responsibility for security was able to get through to any of those groups to fix their parsing.

MikeA • May 7, 2020 6:05 PM

Leaving the usual question when dealing with Apple and Updates:

Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous coding,
Or to Update against a Sea of troubles,
And by updating Suffer?

Simon Woodside • May 7, 2020 8:04 PM

Heh, 20 years ago when I was at Apple, XML was new and hot and plists were switched from a custom text format to XML. Definitely seemed like a good idea at the time. XML, how did you go so wrong?

lurker • May 8, 2020 2:38 AM

• XML is terrible.

XML was supposed to save the world, One Markup Language to Rule Them All. Before that was SGML, and before that …

• iOS uses XML for Plists, and Plists are used everywhere in iOS (and MacOS).

iOS and MacOS do things to vanilla XML so that it’s no longer human readable in a standard text editor. Sometimes this is understandable space saving compression, sometimes it’s a childish attempt to hide the contents from people snooping around inside their ‘puter.

• iOS’s sandboxing system depends upon three different XML parsers, which interpret slightly invalid XML input in slightly different ways.

The reason for three different parsers is the three different formats of plist mentioned above. I don’t believe Steve J could have signed off on this. He would have understood the need for One Parser to Rule Them All.

jbmartin6 • May 8, 2020 7:08 AM

In the long run, is it better to have different parsers? That way, a flaw in one does not necessarily lead to complete compromise. With just one a parser, a single flaw would be a complete failure. Defense in depth.

Dave C • May 8, 2020 10:29 AM

@jbmartin6

better to have different parsers? … a flaw in one does not necessarily lead to complete compromise

That would only be true in a system that used the multiple parses and compared the results, either discarding any one that disagreed with the others or failing on any disagreement. That’s not at all what’s going on here which is never ever a good idea and give no benefits with a clearly non-zero cost.

It's Necesaary! • May 9, 2020 11:00 PM

3 different parsers is not only normal, but also generally necessary, if different parts of your large sprawling system is written in 3 different languages! As already mentioned, it’s also normal even in the same language, if different groups of people independently needed to parse stuff for different reasons or in different eras.

For example, I’ve written a program that couldn’t use an existing parser for something (non-xml related, but the point applies), because it needed to explain to the user where the parsing problem was… no existing parser provided that capability… so you’re left with either forking an existing much-more-complex-than-needed project to make a new parser out of it, or just making a new (and simpler) parser yourself from scratch… Different needs for different projects. That’s normal. I get it, other projects only needed to tell the user that the file was unparseable, with no explanation given as to exactly where the problem occurred in the file.

The problem is this: the solution is a much more walled garden than apple has already done. You want to only allow a single parser on the whole device? Great! You’ll have a system that just can’t run most stuff. Since most stuff in the world isn’t written by you, personally, just for your personal needs alone. It’s a problem with general purpose computing and general purpose computers, it always has been, and it always will be to one degree or another, as long as anything “general purpose” exists. Small improvements can be made, sure, but not totally locked down, unless you are willing to accept the consequences: no more general purpose computing.

It's Necesaary! • May 9, 2020 11:14 PM

Oh… my point is exactly why a 4th parser was written to “fix” this… No existing parser was written with this kind of security in mind? You gotta write another… Either that or dump the format, and use a proprietary format… but that doesn’t really solve the issue, since a proprietary format now needs another parser too…

Or perhaps you’ve written a completely guaranteed-to-be-safe (https://en.wikipedia.org/wiki/Formal_verification) parser that can be used instead? One that can fit every possible need that could ever arise forever? Note that these two things are opposites: for formal verification you need to pair it down to the bare bones that you need, not soup it up with every possible bell and whistle that could ever be invented… unless you’re happy to to pay millions for it…

This is not a problem unique to XML. All parsers have this issue, and to some degree at both high and low level, everything in a computer is something that is parsed.

It's Necesaary! • May 9, 2020 11:39 PM

@Steve Friedl

TIL why JSON doesn’t allow comments.

Also one of the reasons why JSON is unsuitable for configuration files that need to be maintained by actual humans (search google for this, you’ll see tons of horror stories)… Ever tried to experiment with a package.json file to try to get something working, and couldn’t save your partly-working experiments anywhere, and couldn’t document what worked and what didn’t, without… what… a separate txt file to explain it? devoid of context? oh my. don’t get me started how many hours I’ve wasted on this.

And… a plist file is a configuration file, yep. Is it ever intended to be edited by hand (in a text editor)? Or maybe just that GUI (graphical) tool? Do you intend to have anyone edit it that’s not sitting at the actual keyboard and monitor physically attached to that computer? Hint: the whole internet runs on remote systems, not just local ones… They don’t sit in the bedroom corner of the guy that maintains them.

Tom S. • May 12, 2020 1:59 AM

This exploit didn’t happen because of XML. It was ignorance of history and bad design.
Internet Explorer 6 & 7 between XP & Vista in 2007 also had the problem of multiple validating parsers making security decisions & exploiting the differences between them. IE granted privileges to code executed in the browser based on what Security Zone it calculated the site belonged to. A consistent feature of many exploits then was trying to be classified as local. Domain name tricks, IP address literals (I think octal worked @ one point), and more.
A chief point of IE7 was to fix this canonicalization problem. In conjunction with the IP stack rewrite, MS pulled all of the URIs through a single canonicalization process before making the Security Zone calculations. Things improved.

Wikipedia’s entry for Canonicalization has some fair examples. International domain names & Unicode concern me most. XML examples are included, as is a reference to a “Canonical XML specification”.
Makes me wonder how well Apple’s developers were aware of the perils of their architecture (multiple components making security decisions in different ways) and how compliant they were with the W3C’s recommendations from 2008.

Thunderbird • May 12, 2020 1:03 PM


In the long run, is it better to have different parsers? That way, a flaw in one does not necessarily lead to complete compromise. With just one a parser, a single flaw would be a complete failure. Defense in depth.

This is a common mistake people make when thinking about security issues. If the failure of a single component out of a group leads to a compromise, the metaphor to think of is “the weakest link.” If two or more components must fail, then it is reasonable to think of “defense in depth.”

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.