Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple iMessage Zero-Click Hacks

wired.com

Post reply on HN
Print view View original

131–140 of 156 posts

Re: Apple iMessage Zero-Click Hacks

#131

Post by est31 »

harg wrote: post #125
est31 wrote: post #27

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Dancing_pigs

For the general population this probably applies, but in the case of this exploit it looks like it's targeted at specific individuals. If you were someone being targeted by an oppressive government, for example, you might be a bit more cautious when clicking on suspicious-looking incoming media so I think the suggestion has value.

Fair point. The point still stands but in a weaker way though. Even people who say/claim they care make mistakes.

The idea is that contacts can still send you media without prior approval. Do their children never make mistakes? Do their spouses/gardeners/etc.?

Re: Apple iMessage Zero-Click Hacks

#132

Post by simondotau »

dannyw wrote: post #110
eloisius wrote: post #88

I got corrected last time this topic came up. I originally thought Messages was part of the OS and not a pre-installed userspace app. However, if it's in userspace, why is it such a vulnerable vector for compromising the phone? Is there some privilege-escalation component to this that I haven't read about?

iMessage is one of few apps that have broad permissions to execute code in response to notifications. For other apps like Telegram; the server can send a predefined notification message. For iMessage, when you get something even from someone outside your contacts, its daemon invokes specific code to handle the message, and its attachments. Whilst this doesn't help if someone opens the app, it does at least change thi…

A bit off topic, but when did we ever expect integrated apps to be restricted to App Store rules? They're literally sold as part of the device, not as an app through the App Store.

Re: Apple iMessage Zero-Click Hacks

#133

Post by simondotau »

raspasov wrote: post #17
gjsman-1000 wrote: post #5

I wonder if Apple's devs are just going to say, screw it, we'll rewrite the whole thing in Rust with audits and formal analysis the whole way...

Rust or Swift. I am not a security expert, but I'd bet that re-writing in either would reduce the amount of such embarrassing exploits at least 10x. From what I can tell, the combination of unsafe-by-default languages like C/C++/Obj-C and the way the human brain works is Not-A-Good-Combination© . Too many opportunities for error.

Low level library stuff like JPEG and PNG parsing/decoding is exactly where Rust could offer massive security wins for a relatively modest change of code. The main requirement would be to ensure that the Rust versions had absolute feature parity with zero regressions.

Re: Apple iMessage Zero-Click Hacks

#134

Post by cmg »

dannyw wrote: post #109
bb123 wrote: post #106

Earlier quoted context omitted.

I wouldn't want this at all. Just off the top of my head I can think of a ton of use cases this makes hard: * I ask a seller on FB marketplace to send me some pictures of an item * I need to send pictures of some documents to my solicitor * A new friend I've just met in a bar tries to send me her contact card * My mechanic tries to send me a PDF of the invoice for his work Sure, there are ways around all of these, bu…

All of this can be on a "Tap to view" basis for the first media received. Right now, iMessage processes everything in the background upon receiving. That enables zero click, instantly delete message attacks. The only trace you have is a random imessage sound, or vibrate, with no corresponding notification. Can be tuned to send at 4am when most people have do not disturb on.

Except people want to view the content.

If they think my friend has sent a picture, or a business has sent an invoice, they're likely to click it.

Especially in the 3 receiving situations that bb123 outlined (1, 3 and 4) you're not likely to have the contact info, or it's plausible that the person could be using another phone to send that message.

Now - I know to check the sender, don't click strange links, all of that. I run trainings on how to avoid phishing and improve personal & organizational digital security. But it comes down to the fact that people are using technology as a tool.

Apple made headway with BlastDoor but it's clearly not good enough.

Re: Apple iMessage Zero-Click Hacks

#135

Post by hjnilsson »

xvector wrote: post #119
kenferry wrote: post #81

Earlier quoted context omitted.

It’s more like, if you send someone a photo, iMessage will decode the photo and display it. If the imaging library has a bug a maliciously crafted image may be exploitable. iMessage has more integrations than that too. If you send someone a URL, e.g., the recipient will see a preview of the content. iMessage does a lot to mitigate the attack surface, but people still get through.

Can Apple not rewrite the parsing components in a memory-safe language?

Replacing libjpeg, libpng, h264 & h265 codecs etc. is a gargantuan task. Even if Apple employs another 200 rust programmers (which don't exist in the market – so not possible) it would take years before that project is close to finishing. So intermediate solutions are necessary until then. It is also likely a rewrite would introduce other security issues (not memory safety issues) which would take time to fix.

Rewriting these libraries is probably also a common good, that would be better done through open source initiatives.

Re: Apple iMessage Zero-Click Hacks

#136

Post by upofadown »

johnthuss wrote: post #83

Contrary to the article, blocking ALL media besides plain text from random senders who aren't in your contacts is exactly what most people would want and should be the default. I don't see any downsides to that approach.

Perhaps this idea could be extended to treating content differently for all messages from unverified identities. Getting people to verify identities in an end to end encryption system is a huge problem. This could provide a conceptual hook that would mean that unverified contacts were untrustworthy contacts. This would be a state, rather than something that you get nagged about from time to time.

Otherwise an attacker will usually be able to figure out a way to fake a message from someone already in your contact list.

Of course iMessage doesn't do identity verification which is why it does not have effective end to end encryption in the first place. So they would have to solve that, perhaps larger problem, first.

Re: Apple iMessage Zero-Click Hacks

#137

Post by ricktdotorg »

KaiserPro wrote: post #120
dannyw wrote: post #109

Earlier quoted context omitted.

All of this can be on a "Tap to view" basis for the first media received. Right now, iMessage processes everything in the background upon receiving. That enables zero click, instantly delete message attacks. The only trace you have is a random imessage sound, or vibrate, with no corresponding notification. Can be tuned to send at 4am when most people have do not disturb on.

This a million times. Whatsapp of all things has this. (mostly to save on bandwidth, because whatsapp as all about efficiency at one point) There is no real reason to auto process untrusted data. I would have thought we'd learnt from the years of exploits outlook dealt with in the late 90s/early 2000s.

Sometimes my dad sends me photos over Whatsapp, and I have noticed that they appear in my Photos app before I have opened/viewed the actual Whatsapp message. I assume that this is happening because i have given Whatsapp access to my Photos. But, it does appear that attachment/image processing is happening via Whatsapp without my control/without my viewing the message + its attachments.

Re: Apple iMessage Zero-Click Hacks

#138

Post by kalleboo »

azinman2 wrote: post #25
raspasov wrote: post #13

Is it a fair assumption that any code written in C / C++ / Objective-C has a high likelihood of allowing zero-click hacks?

Objective-c has bounds checks and lengths built into NSData, NSArray, and NSString… so many of the buffer overflow techniques likely won’t work against it. However, images and video seem to hit C++ code and from all of the past CVEs it seems this is a giant attack surface over and over again. I’m surprised this code isn’t being rewritten in something like Rust, but perhaps there are more things going on at play, like…

> I’m surprised this code isn’t being rewritten in something like Rust

I imagine the internal discussion is something like "by rewriting it, we will just introduce 100 new bugs. once we squash these last few bugs in the current tried-and-tested C code, it will be bulletproof!"

Being Apple I imagine they would prefer to rewrite it in Swift, but Swift may not be mature enough

Re: Apple iMessage Zero-Click Hacks

#139

Post by webinvest »

johnthuss wrote: post #83

Contrary to the article, blocking ALL media besides plain text from random senders who aren't in your contacts is exactly what most people would want and should be the default. I don't see any downsides to that approach.

Or anyone that you haven’t replied to yet. I text many people who aren’t in my contacts.
Post reply on HN