Stealing your SMS messages with iOS 0day
wojciechregula.blog
wojciechregula.blog
I think just a simple if statement would work better than an "AI".
Solution: Dont install apps outside the app store.
Since apps now auto-update each night any one of your apps could theoretically add this code tonight couldn't they?
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.
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.
> 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're conflating two separate issues. Microsoft has a certification program for Windows programs, Linux has extremely nuanced permissions, SELinux, etc.
This has been solved elsewhere but the walled garden of iOS is deliberately ill-designed and is not a robust solution.
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.
I'm curious what your definition of robust is.
One of these methods has a much better track record than the other.
If Apple would allow people like me to control the devices we buy, I would finally have a home in the mobile market.
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.
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.
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.
They're not hiding anything from you about their walled garden.
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.
lol, I wish.
That's like saying "I've rented from Blockbuster Video from over a decade without needing to view videos Blockbuster doesn't carry"
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.
https://www.wired.com/2009/05/apple-rejects-bittorrent-iphon...
To be fair, I can't think of anything distributed via torrent that you'd want on an iPhone that isn't copyright violation.
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.
It's misleading to call something an "iOS 0day" if actually does not apply to almost every user of iOS.
- 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.
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.
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.
I wouldn’t be too sure.
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.
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.
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.
If you're installing from source, that's another thing.
Also a decent text editor shouldn’t be considered unusual software.
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.
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
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.
The App Store verification process does not seem like a reasonable single line of defense. If applications can just get data from the rest of your phone without prompting the user then something is seriously broken here.
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.
In this case it's just a plist, which makes things even easier.
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.
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.
If you’re trying to make a point, just make your point, don’t waste my time by leading me around with questions.
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.
<!--->
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.