The exploit author's blog post on why the extra entitlements work (and how Apple fixed it) makes for a more interesting reading: https://siguza.github.io/psychicpaper/

I think a much simpler solution would be to just use one consistent XML parser. Throwing AI at things is not a good general solution. Black-box AI models may work in the common case, but they have edge cases with bizarre behaviors that are poorly understood. You'd end up with a result likely worse than this.

I understand the attitude of some saying Apple "should implement the absolute correct parser". But such way of thinking is not practical. The question is not whether there is an "absolute correct parser" but much more when can we have a relative correct and safe parser. The way Apple had to wrestle with 4 different implementations of the same parser function shows that the issue is not trivial. Other XML parsers may have the same problem, too, albeit uncovered yet. Using AI to flag down unusual entitlements and other potential hacks in the future is much more practical and future-proof than race for the absolute correct guard. The AI should not replace a correct implementation but rather augment it as an additionl security tool. I'm certain many organization would go this way in the near future (if they not already did!)

> Apple didn’t develop an AI to flag apps with suspicious entitlements

I think just a simple if statement would work better than an "AI".

They would be caught if this was submitted to the App Store. This applies to self-signed apps by those with a developer certificate.

All it's doing is POSTing the contents of /private/var/mobile/Library/SMS/sms.db to a server. You can't get an app into the app store that haz the required permissions to access that file.

Solution: Dont install apps outside the app store.

You’re missing the point:

- AppStore or not, you should not be able to access this file in an app. The exploit (plist parsing bug) is about breaking out of the sandbox and getting the permission to access system files (and much more!).

- Also. There is nothing stopping someone for using this technique to publish an app in the AppStore officially.

Or maybe I should have said “was”. Best case scenario Apple would retroactively check for naughty plist files in Apps submitted to the AppStore present and past, and ban developers that used the same hack. That being said, this is reactive and the damage would already be done.

This hack is not using a private API or doing something that Apple would have caught during App review. Even the system file path could be obfuscated (or downloaded from Internet later on).

So “don’t install apps outside the App Store” did not really help in this case.

> Also. There is nothing stopping someone for using this technique to publish an app in the AppStore officially.

That's not accurate, the entitlements parsing logic on the App Store submission system has always caught this, it's the client side parsing that doesn't.

You can't submit an app to the store that uses this exploit, because the store will reject it as having invalid entitlements.

Indeed. I was wrong to assume Apple would not have yet another XML Parser somewhere else :)

In that case it would only work with side loaded Apps signed with enterprise and developer certificates.

I stand corrected.

That being said I wonder... since we have two parsers on the device and one in submission process, if a more clever variant of this bug would have worked... I guess we will never know. For sure that parser is rock solid now.

> For sure that parser is rock solid now.

I wouldn’t be too sure.

thatsthejoke.jpg

Do you know if TestFlight uses the same entitlements parsing logic? It may have been possible to exploit users' devices through beta versions.

TestFlight apps are uploaded to App Store Connect as well.

> There is nothing stopping someone for using this technique to publish an app in the AppStore officially.

It has not happened though. Only app which has been in the App Store and utilized private entitlements, from what I’ve seen anyway, has been Uber.

That's a terrible solution.

Giving full control to one company of the thing that can be published, discovered an install is a receipe for all what's wrong with monocultures.

Don't get me wrong, the app store is a fine service. And that it's the default experience for beginners is a reasonable compromise.

But assuming it as the only channel is like a hospital refusing to heal people that eat processed meat because WHO declared it carcinogen.

> You can't get an app into the app store that haz the required permissions to access that file

The one thing that was never clear to me was whether Apps were able to be submitted to the store with this buggy entitlesments file.

I've used iOS for over a decade without needing to install apps outside of the app store. I would guess that the vast majority of iOS users share that experience. I understand you might be frustrated by those limitations, but to say "hold off on this until it's fixed" seems pretty reasonable.

It's pretty ironic to hear a complaint about the walled garden, when the only apparent way to solve this "0day" is probably going to be to put up another wall.

You don't know what apps you're missing if you can't see what apps would exist without the restrictions.

That's like saying "I've rented from Blockbuster Video from over a decade without needing to view videos Blockbuster doesn't carry"

Completely agree. It's also the view that people held regarding blackerries pre-iphone.

A hardware keyboard was essential because the alternative was not an option.

As someone who used to jailbreak, I've definitely found tools in the past in the jailbreak store that were lovely, and a large chunk of those have now wound up in iOS by default too.

I've also since determined that the tradeoff (less security, more features) isn't one I'm still happy to make anymore, so have given up and accepted that I can do what Apple permits, and that's it.

It's not the ideal solution, but the ideal solution doesn't currently exist, and this is the least-bad in my view of the tradeoffs involved.

But we know what's possible because other platforms like android exist.

$99/year is peanuts, that's less than 1 hour of developer time. All it does is prevent spammers from creating a shitload of free accounts.

You're not thinking of programmers from developing countries. It can be several days wage there.

> $99/year is peanuts, that's less than 1 hour of developer time

lol, I wish.

There's a difference between your salary, what you cost to the company, and how much they charge the customer for your time.

Well ... it might not be what a developer is paid, but it's the value a developer creates for a business (experience and training withstanding of course), if you catch my drift.

99 cents a year would stop spammers creating a ton of accounts too

Making it harder also heightens the bar so low-quality or malicious apps don't get in.

For me the walled garden of iOS attracts me to the platform. Its apps are relatively safe, stable and curated. Sure, these restrictions might suck for you as a power user. For me, someone who makes phone calls, chats with family, takes pictures and reads the news this is just perfect. I don't need to think a lot about security because the platform thinks about it for me. For you it feels like prison, for me it feels like one thing less to worry about. For you it's ill-designed, for me it's designed for me the consumer.

I'm curious what your definition of robust is.

Not the person you were responding to, but: implements security with fine-grained and system-enforced permissions, not human approval for apps.

One of these methods has a much better track record than the other.

It sucks for me as a power user because I prefer Apple's corporate ethos, but their increasingly quirky UI and no recourse for things like alternative launchers make it an automatic no-go because I can't stand Apple's interfaces. It seems silly to most people but I get physical anxiety from interfaces which don't behave consistently or make me feel claustrophobic, and I've grown tired of relearning iOS every few years. To the point where I'm using hole-ridden Android devices with bags of telemetry by default, but with a consistent launcher I've used for many years and know how to navigate. No hidden UI tricks.

If Apple would allow people like me to control the devices we buy, I would finally have a home in the mobile market.

>but I get physical anxiety from interfaces which don't behave consistently or make me feel claustrophobic

I feel terribly for you. I can't imagine being in my own way so much that Apple's UI would give me physical anxiety.

It's not "in my own way", it's some kind of physical disorder where I legitimately get a sense of panic if things aren't responsive for more than a couple hundred milliseconds when they should be, a great example would be when explorer.exe jams up in Windows and everything severely stutters.

I wish I didn't deal with this but a little sensitivity towards users like me would be nice instead of ironically writing us off as close-minded. I have diagnosed OCD and it's just a facet of that. It can be quite frustrating at times when I'm trying to use an interface and, say, intrusive thoughts lead me to repeating body movements like clicking or picking up and dropping my mouse and next thing I know my browser is closed and I've opened up another program without even realizing. Like it happens all day while I'm working and the more invisible my interface the better. It's not easy to overcome these physical impulses and reactions. I still deal with vocal tics and stuff like that.

That doesn't really sound like an issue with the interface, though. Again, I'm sorry you have to deal with that but you're basically saying that companies need to account for the possibility that someone who clicked the "X" to close a window may not have intended to close the window. That's just crazy talk.

No, that's not what I said. If you want to have this discussion in good faith then let's not mince words.

I said a proper platform allows user control and customization over the interface, providing a way for users to continue using interfaces that make sense to them even if some young engineer at Apple finds a clever new way to shove some functionality into a screen gesture.

This isn't crazy talk. It's exactly how my Linux-based computer and Android-based phone operate and I've been using the same window manager / launcher for over a decade, while the mainstream default ones like Gnome 3 continue to make the strangest and most anti-user design decisions. I just bought a MIUI phone and if I couldn't flash my own Paranoid Android ROM in the coming weeks I would have to return this phone because the UI is bonkers.

As a technical user, I share in your frustrations. iOS may be more secure out of the box, but it's an all-or-nothing solution. Either you take what they give you and put your faith in the almighty Apple, or you break out and have no protection at all.

Unlike other platforms, where there is a range of options to us, where if we work hard enough, we can make our platform more secure, while still maintaining our freedom to do as we please, because we know what we're doing.

That said, I remain grateful that there's at least one mass consumer facing platform that is secure by default and user friendly. For the vast majority of the world, this is more valuable than the ability to tinker.

For me personally, it ends up being a toss up. I lament my restrictions, but I'm grateful for the significantly reduced amount of technical support I'm required to do now compared to the (good|bad|^$) old days when a PC / laptop was everyone's primary computing device.

There's such a simple solution: don't buy an iPhone.

They're not hiding anything from you about their walled garden.

> There's such a simple solution: don't buy an iPhone.

Is there a platform that gives me the freedom to run what I want, provides a decent security model, doesn't spy on everything I do, and if you squint just right, 'just works'?

If not, there is no simple solution, there's just different tradeoffs in a huge pile of poop.

Yeah, I don't understand why this position needs defending. Both Google and Apple's app stores have major problems, and they could learn a little from each other.

That's a real solution because the vast majority of iOS users are already using this solution through their inaction (i.e. never installing anything outside of App Store and not adjusting their phones to be able to install anything outside of App Store), and thus are not vulnerable to this exploit.

It's misleading to call something an "iOS 0day" if actually does not apply to almost every user of iOS.

Apple considers integrity of their entitlements as part of the security model of iPhone. As such, an exploit that allows people to arbitrarily sign applications with restricted entitlements is absolutely a iOS 0 day.

While I agree, the barrier for entry here isn't that big so I'd say it still qualifies.

One of the reasons why it's so restrictive is so developers can't do things like the attack in the article. You can't have the protection Apple offers and also have the freedom to do things the protection protects against. That's a tautology.

Why does apple "protect" me from bit torrent clients but ChromeOS and Android do not?

It’s a legal thing. Creating such an app goes against the AppStore rules. Same as porn.

https://www.wired.com/2009/05/apple-rejects-bittorrent-iphon...

Gotcha.

To be fair, I can't think of anything distributed via torrent that you'd want on an iPhone that isn't copyright violation.

It's fair to say that BitTorrent main use cases can not be said to have been in most copyright holders best interest, but as always, the details are important.

I don't personally think BitTorrent is super useful to most phone owners, but then again well over 99 percent of apps are not useful to me, so I don't know if that's an important metric?

Best interest of Apples commercial partners, seems to be what it is about, not what is reasonable, fair, or good. In other words, it wouldn't matter if there actually is/was things on BitTorrent that you actually wanted on your phone, because you are not the most important party here, the content owners are, and I think that is wrong considering the role digital devices has come to play in society.

Considering a lot of people only have phones today, I think Apple is clearly stepping over a line with how they manage their app store in a much broader sense.

Few would think it to be reasonable, that a main producer of printing presses would lease them on the condition that only certain articles can be printed, or maybe decide what magazines a kiosks on the sidewalk is allowed to sell - only because they were paid to build the shack - would be an even more apt comparison?

Tangentially, as we don't have any real equivalent to public spaces in the digital realm, it can be argued that the public spaces resides at least partially in whatever digital spaces are created to perform a similar role as the equivalent public space. An interesting thought, but I digress.

It boggles my mind that it is suddenly seen as okay because the "paper" is now a $1000 digital device, instead of a cheap piece of paper?

Since you can choose what paper to buy any day of the week, but what device to buy only rarely, I would expect society to put strict rules on the content curation of device producers/platform owners, but instead the opposite seems to be the case.

So why aren’t torrent clients banned on Android, ChromeOS, Windows, and MacOS? Because I might download a CentOS installer after downloading those 2TB of copyrighted movies and music?

Presumably because none of those platforms actually ban any app, unless I'm mistaken?

I believe crypto miners are banned.

Chrome OS is not protected by Apple.

But it is protected by Google? I fail to see your point.

Apple knows how entitlements work and scan every release you try to upload for distribution. The app bundle is signed with an Apple signing key when it goes live, so you can't just randomly change the file once it is on the device.

Evidently Apple does not know how they work, as their multiple parsers can’t get them right ;)

If their scan included an XML parser with the same flaw as CFPropertyListCreateWithData, then yes you could get it published without them noticing.

Apple tracks every time you change it and manually reviews it. In even more sophisticated means after what Uber did.

Note that Uber was given that entitlement by Apple. It was explicitly granted an exception to use a private entitlement (which is in of itself unusual) and then submit such an app to the App Store.

Apple's XML parsers apparently are not catching this due to the comment trick.

So the security relies on a human catching it. There are many ways to hide text from a human, IE padding it out with whitespace, character encoding tricks, etc.

"reading the SMS database of an iOS device to which you have full unlocked physical access"

The point is that someone could slip this code into an innocuous-looking app and trick an unsuspecting user into installing it.

It doesn't work via the App store, apps which require you to bypass the app store are not innocuous.

ish requires bypassing the App Store and is one of the only ways to run quite a lot of pretty basic everyday software on iOS.

FWIW, I believe that all TestFlight app releases also undergo the automated portion of the App Store approval process, which would be able to catch entitlements.

If you're installing from source, that's another thing.

Correct. This is why iSH cannot dynamically generate code like say UTM can and must use software emulation via a threaded interpreter.

Yeah, a Linux shell is not what I would call "basic everyday software" that I need to run in my phone.

I need ssh and git for a lot of everyday stuff personally.

Also a decent text editor shouldn’t be considered unusual software.

It would have worked and passed through the App checks. It’s not like the App is using private APIs.

Now that Apple is aware of this class of bug, they may add automated checks to the plist files containing a super strict XML parser.

Their existing parser used during App Store submission already catches this. It’s the plurality of parsers on the device itself that allows this to happen when sideloading.

But not a security conscious user who knows once the USB cable is plugged in the device is compromised.

Most security-conscious users do not assume this. Newer iOS versions ask for credentials (and all recent smartphones that I've used ask for credential-less permission) before transferring data over USB.

Installing an app even through a cable requires clicking through permissions.

There are probably apps out there exploiting this already since this seems to have been known about for a long time and only recently patched.

Like the ‘zeroday vulnerability’ of users pasting commands into a prompt.

There's nothing technical about this that couldn't be exploited by any published app, so far as I can see. It doesn't look like you need physical access.

I cannot be done by an app published via the app store.

it pains me that there is no way to legitimately export your message history for archival. I know it's backed up with icloud and local backups, but I would love the ability to view message history, run analysis of my convos, and "archive" convos to date (i.e. I want to be able to go back and read the convo, but I don't want to have the 13.4TB of gifs on my phone anymore)

So, I may just replicate this "0day" and run it on myself... will be fixed soon, but at least I'd have a single snapshot

If you do a local backup, there are tools to decrypt it (if encrypted) and view/dump the messages. If the backup is not encrypted, you can skip the decryption step.

The message db is just a sqlite file.

iOS backups are in ~/Library/Application Support/MobileSync/Backup/ although the file names are obfuscated. There are tools for browsing the obfuscated file names, or you can just grep for a known string in your messages, find the sqlite file, and rename it to sms.db.

My friend wrote a cool tool called sqlite2json at my insistence which, if you don’t know/care to use sqlite, will dump an sqlite file to json. It’s available on pypi for installation via pip.

if you enable iCloud sync you can just copy the database (SQLite) off your mac. ~/Library/Messages/

It's actually just SQLite? No weird proprietary format or anything? That's both surprising and awesome to hear.

CoreData, which is commonly used as object storage by apps on Apple’s platforms, is backed by SQLite.

You can use third-party software like iMazing or PhoneView to extract the message history

Looks pretty cool, didn't know about iMazing. The new iPhone/Music app in Catalina is a pain to use and has lost functionality. Thanks for the recommendation!

I personally use iMazing for this, it’s pretty great

I'm actually eager to use this and write an app to finally migrate all my messages from Android stuck in an xml since I didn't use Apple's migration tool initially.

No, this is based on the Psychic Paper “exploit” that was described a few days ago that allowed developers to sign their apps with extra entitlements, including ones that would allow for accessing files outside of the normal application sandbox. (To be clear: there is no app, other than Messages, that should ever be able to access your messages. Such an app is not allowed on the App Store.)

Ah, thanks.

Good example of using `http.server` in python

Looks like its actually just a plist/entitlements request in the app asking for access to do something and being allowed.

I'm suspicious if this works in App Store apps though, from memory Apple checks what permissions the app is requesting as part of the submission process.

Definitely wouldn't pass the first validation step when you upload a binary to app store connect

What? XML is super easy to parse. If you think XML is hard to parse, maybe you're trying to do it with a DOM interface, or wasting a bunch of time manually shuffling data around. The XML 1.0 spec is super short, once you ignore DTD stuff and things like entity references.

In this case it's just a plist, which makes things even easier.

Just google "xml parser exploits". Parsing basic XML might not be hard, but when you get into the full spec and accompanying technologies the surface area of attack is huge.

And yet Apple has a handful of parsers which all parse it differently…

Can you elaborate on that? I know it's really in fashion to hate on XML here, I just want to understand what people's complaints are.

Having written parsers for JSON, YAML, and XML at various points, I can tell you that XML was not much more complicated than JSON. It's got a good, clean spec and not too many rules.

I think Siguza’s blog post describes the background for this issue in a remarkably accessible way: https://siguza.github.io/psychicpaper/. You may also find libplist (a third-party plist parser)’s woes interesting: https://github.com/libimobiledevice/libplist/issues/83

The first article may be interesting or it may not be, it's four thousand words long and I don't know what I'm looking for. It sounds like there are some bugs in XML parsers. Well, people put bugs in simple code all the time. People also try to be clever and make parsers Very Fast, and people are also lazy and don't test simple edge cases. Mix these together and you get bugs.

Then, some third-party plist parsing library written in C can segfault. I'm not surprised! Does that mean XML parsing is hard? No. It happened because it's easy to make a library written in C segfault, no matter how easy the problem you're solving is. C is like that.

I can say that I have actually authored a different plist parsing library in C, and I don't remember running into a bunch of segfaults. What I do remember is that of the major plist variants, the XML variant was the easiest to work with. The text variant is more concise but you can't use an off-the-shelf XML parser. The binary format is poorly documented. Clear win for XML plists, in my book.

I'm not going to take Apple's hit-or-miss software quality or bugs in some random third-party library as an indictment of XML.

Are you sure your parser parses it exactly how Apple’s does? Are you sure I couldn’t just fuzz it a bit and get it to crash?

Do you want me to explain my QA process to you? Or are you just trying to make a point?

If you’re trying to make a point, just make your point, don’t waste my time by leading me around with questions.

I am, actually: writing a parser that is bug-for-bug compatible with Apple is nontrivial, and you haven't given me anything so far that convinces me that you realize that complexity and have dealt with it in the way I am describing.

I asked because a conversation about whether I “realize that complexity” is exactly the kind of conversation I want to avoid. I’m not here to litigate how good a developer I am.

The sense I’m getting—to be honest—is that you want to ask me questions until I “submit”. Maybe I’m off the mark! There are a lot of interesting directions that a conversation about parser correctness can go. You can discuss different goals, the idea of parsing to a spec versus matching the behavior of a reference implementation, fuzzing, attacks, stack overflow, and ergonomics like the quality of error messages. It’s an interesting subject.

Note that this has nothing to do with how good a developer you are. I am specifically talking about your accuracy with parsing property lists as Apple does. You could have a perfect, XML spec compliant, stable parser and it would still not be relevant here because Apple does not use one themselves and third-party implementations which aim to be compatible must be bug-for-bug compatible.

You’re just rewording things that you said earlier and elaborating.

Right, because I'm hoping that might help you understand what I was trying to say better. Were you expecting something else?

I was hoping for a conversation.

TLDR: the gist of it is that one of Apple's XML parsers treat XML comments wrong and would advance a char pointer only two bytes when it should advance three bytes (eg. past "!--") such that this invalid XML comment passes

     <!--->

whereas another parser correctly rejects the invalid XML comment.

I don't see how this is a reason to hate on XML. A similar bug can surface in any property file parsing routine for a format having commenting syntax. It's amplified, though, by Apple (according to TFA) using four different XML parser implementations for parsing entitlement and other property (.plist) files, and the lack of testing/dilution of efforts that goes with a situation like this. I'll add that .plist files (or other simplistic property files for that matter) IMO had never a good reason to be XML. XML/SGML is really for delivery/authoring rich semi-structured text in a plain text editor (and is second-to-none for this use case). To me it seems that in this case using XML in the first place because it's already a widely (mis-)used format for general-purpose data serialization, and then not actually using an industrial-strength XML parser (such as libxml2, expat, or xerces) but coding your own ad-hoc XML parser instead is particular bad practice.

Property lists have a binary format. The XML one is convenient because you can open it up in a text editor and modify it by hand.

XSLT is not that bad... I'd take it over c++ templates and many other things any day.

Compared to Javascript it is small and well defined AFAIK.