Hacker News new | past | comments | ask | show | jobs | submit login

> The exploit involved PassKit attachments containing malicious images sent from an attacker iMessage account to the victim.

Man, iMessage is a security disaster for Apple. No matter how much work they do in other areas, it seems like they'll paying for a while for their decisions around the iMessage architecture.




Some of the problems with iMessage have to do with the fact that it's integrated with the system SMS app. It seems that there are a large number of legacy requirements in the GSM spec that require the Messages app to be privileged in some way, especially with regards to automatic processing of data received. There have been plenty of iMessage or Messages related vulnerabilities.

I do wish there was a way to turn off automatic downloading of attachments like images etc. from at least non contacts. I think many/most other chat applications, by default, sanitize and/or format images and media on upload on the server by transcoding image data to prevent things like this and save bandwidth (e.g. Facebook/Meta appears to recompress images server side). However, there are obviously security and privacy considerations to doing this, and the client is not exactly something you want to trust to do this, so I can understand why they would be reluctant to implement something like this.

Perhaps this is one potential use of Treacherous (trusted) computing/remote attestation - the client runs a remotely attested signed binary code that will read an image file, encode the pixels as a jpg, and output a signed output that will only be accepted by the server if untampered.

Obviously, there would be issues with that approach as well, but it could potentially prevent the use of the iMessage network to send "crafted" media files.


Apple have a service which attempts to do this, BlastDoor. The issue here is feature surface area unrelated to GSM. My guess from the CVEs is that this exploit revolves around sending a valid Wallet/PassKit item attachment which has a malicious image. The payload is safely _deserialized_ by BlastDoor itself, but is then passed off to the PassKit framework which happily detonates it.

IMO Apple should make a middle ground Lockdown mode - something that still allows attachments (which Lockdown mode doesn't, making it difficult for many users to employ), but forces them to be 1-click. This is something I would use personally and would at least protect me from getting 0-clicked by attacks like this; I'd never click a Wallet item from an unknown sender, but I also can't live with the restrictions in Lockdown mode.


I look forward to reading the Google Project Zero blog post about this one given how wild the last one was.


Loading anything other than text from unknown senders...


It pisses me off man. If someone sends you a link on iOS, you can't copy it without doing a long press that loads all the spyware on the website in a preview window


With lockdown mode on, I have to explicitly tap a line of text on the popup to load the preview.


Apple's architectural fix here is to move file parsing and other risky operations into proper sandbox harnesses, and to tighten these harnesses year after year.

This is the path that WebKit has followed, and the sandbox for the WebKit JIT is incredibly hard to break through these days


Also the path that the Messages app is taking https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...


You can enable iOS’s “lockdown mode” which disabled automatic download attachment, JavaScript JIT and other rather hard to secure features.


Doesn't Lockdown Mode fully block message attachments besides images? Not just automatic download.


Yes, I’ve been running it and you can’t click on any attachments.


> I do wish there was a way to turn off automatic downloading of attachments like images etc.

isn't that what Lockdown Mode is for?


One can't even mark all messages as read in iMessage, which seems to me like the most basic functionality. Something is really messed up in how this thing has to run if you can't do that


Try the ... menu > Select Messages > Read All at the bottom of the screen.


They're slowly rewriting the whole thing in Swift which should eventually eliminate most of the non architectural attack vectors. Most of them were mitigated in iOS 14 where they did some rather large architectural changes.

Edit: Further info: https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...


When I look at an initiative like BlastDoor, I'm struck by how unlikely it is that every other messaging app makes a similar investment on every platform. Does WhatsApp have a similar architecture? Has the Gmail app rewritten all its image parsers in a similar manner? Has Tinder? And sure, if you compromise WhatsApp you only get access to its internal memory and may not be able to escalate to other apps or OS storage - but compromising someone's WhatsApp messages isn't any less serious, and there's history of escalation being possible: https://techcrunch.com/2019/05/13/whatsapp-exploit-let-attac...

It's a miracle that these kinds of zero-click zero-days don't get announced every single week. Though maybe they do, and we just don't know about them...


They cannot, because Apple does not allow third party apps to create sandboxed subprocesses.


zero click zero days cost literal millions, sometimes tens of millions

these exploits aren’t utilized haphazardly - someone has to be willing to pay


At least they’re trying? Meanwhile Google has spent 2 decades refusing to release a messenger that encrypts by default because they think they should be able to mine all your personal conversations.

I take that back, they announced encrypted messaging, then never released it, then probably fired the engineer who said it’d be a feature in allo (or whatever their last attempt was).


Your comment does not make sense at all.

You are confusing security (no exploits) with privacy (encryption). The iMessage system is really private (no third party not even Apple can read your messages) but traditionally full of security holes (messages once decrypted can harm the rest of your device).


> no third party not even Apple can read your messages

This is not something that can be stated as fact unless 3rd party clients for a service exist. Apple can, with complete honesty, claim that messages are encrypted at rest/in transit all they want, but since they publish the only implementation of the client, they can modify it at any time to expose the messages to them, in any number of ways.


You appear to be the one confused.

I'm not confusing anything. The entire point of the exploits in question are to BREAK the privacy provided by messenger. Google doesn't provide any in the first place, and actively mines your data. Who needs an exploit when it's never encrypted in the first place?

To further this: you realize NSO isn't selling these exploits to Russian kiddies to steal your bank info, right?

These exploits are used by people like the Saudi Government to uncover a Jeff Bezos affair. They're after politicians/power brokers for the purpose of accessing otherwise secure communications for the purpose of stealing state secrets or blackmail.


> Who needs an exploit when it's never encrypted in the first place?

Someone that can't get a valid subpoena.

Someone that wants to track anything else you do on your phone outside the messaging app.


It not being e2e-enxrypted doesn't mean that the Mexican army can read my messages.


It absolutely does, you're exactly one subpoena away from that happening. Then you're at the mercy of Google deciding whether they care more about you or their balance sheet.


I liked that Google lets you register a different handler for SMS which is at least part way to letting us shut off that 0-click crap channel.


I guess there is something now called "Rich Communication Services (RCS)"[0] in Messenges which supposedly is e2e encrypted.

[0]: https://support.google.com/messages/answer/13508703?sjid=102...


No that's not true. Google just fails miserably at anything social, but almost every chat attempt from them eas encrypted, and now they are pushing RCS, which is also E2EE.


Google started pushing for carriers to use RCS in 2015, and launched it's own app for it in 2019 after that failed to move quickly enough. They didn't start adding E2EE to it until 2020, and it wasn't the default until 2021.


So YouTube isn't a social platform?


Is it? I thinks its rather more like entertainment


Millions of users interact through comments and live streams. Of course it's a social network.


Isn't Messages E2E by default?


RCS is E2EE: https://support.google.com/messages/answer/10262381?hl=en

Though it can fall back to SMS in case you don't have data, which isn't E2EE. I'm not sure what the UX flow is like in that case, whether it warns you and asks for permission to send over less secure channel.


> RCS is E2EE: https://support.google.com/messages/answer/10262381?hl=en

I was under the impression that this is a 'proprietary' extension between Google devices, and that there was no RCS-standard-based E2EE:

> The RCS specification defines several types of messages. Our implementation of E2EE uses varying strategies for encrypting each type of message to maximize user privacy while still adhering to the RCS specification.

* https://www.gstatic.com/messages/papers/messages_e2ee.pdf

They use "vnd.google.rcs.encrypted" in the Content-Type header.


How is that related? Encryption doesn’t really protect against malicious payloads being sent. Quiet the opposite actually as they can’t be scanned / stripped on the server.


Yeah it is irrelevant but tw04 brought it up.


iMessage or android messages? iMessage is E2E by default, unless one or more parties own multiple apple devices, in which case apple stores an encryption key on iCloud and maintains E2EE connections with every connected Apple device. This changes if you turn on Advanced data protection-- then iCloud no longer has the ability to decrypt messages. Somewhat unrelated but ADP is off by default as most customers do not want or need this.


Android Messages, the competitor to iMessage. The parent claimed that Google resists encrypting anything so they can mine your data. I was merely trying to ask for accuracy. I don't know the technical aspects of every Google messaging app but as the other responses in the thread confirm, Messages is end to end encrypted by default for non-SMS messages.


I just checked and Google does have a Messages app, different from the Messages app on my phone, probably by Samsung, which deals with SMSes. According to Play it has 1B+ downloads so it's probably preinstalled.

Anyway, the competitor of iMessage and Messages is WhatsApp. Nobody is sending me SMSes except banks so even iPhone users use WhatsApp to send messages to friends and to groups in my country. If somebody would insist using only iMessage they would be out of the loop. And about Messages, well, I don't have that app, I receive no SMSes, I still communicate with everybody so I guess that nobody uses Messages too.


iMessage is E2E even without ADP, even with groups and multiple devices. The details are complex, but they are publicly documented here[1]:

The issue (I think) you are referring to is that if you enable iCloud backup[2] or iCloud for Messages[3] (both of which move effectively move the storage of the messages to the cloud, either as part of the device backup or as the canonical representation that devices sync from respectively) then the messages decoded on device will be stored in blobs that iCloud has the keys to unless you enable Advanced Data Protection.

[1]: https://support.apple.com/guide/security/how-imessage-sends-...

[2]: https://support.apple.com/en-us/HT211228

[3]: https://support.apple.com/guide/icloud/what-you-can-do-with-...


That would be probably 100% of the iOS users that I know, including my entire family. Everyone's got an iPhone, iPad, Apple Watch, Macbook etc. It's such a nice ecosystem, so it's hard not to get hooked.


Do you have any kind of official doc that explains that behavior ?


iMessage is overall a lot more complicated and integrated than I like it to be. Want to switch accounts, you gotta log your entire user or device out of iCloud. Logging back in will often create issues. Using old Mac/iPhone OS versions creates issues. Messages and attachments are received separately by different devices, and weird things happen when one device is out of space. Deleting messages or blocking senders is per-device. Different devices might miss some messages or even get them out of order. A device waking from sleep often gets messages delayed by minutes (like email), and you're notified a second time for them. And lastly, the "effective. Power لُلُصّبُلُلصّبُررً ॣ ॣh ॣ ॣ 冗" vulnerabilities.

Compared to Facebook Messenger where there's one consistent state in the master server and neatly sandboxed web or iPhone app calling it. And yeah, I know these are partially by-products of e2ee vs traditional, and nobody else has really done e2ee messaging with multiple devices.


The other problem with logging out and back in is that it resets to all iClouds insane defaults that you have to manualky comb over to fix. Its 1000% dark pattern and default nonsense.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: