Live data from Hacker News

Apple iMessage Zero-Click Hacks

wired.com

21–30 of 156 posts

Re: Apple iMessage Zero-Click Hacks

#21
post #16

Wouldn’t be not parsing incoming media unless it’s for someone from contact is a first step that can reduce largely the thread ? So it will stay the same for people in your contact list but a new touch to load for message from unknown person

That might sound good in theory by in practice it's unlikely to go well(by default).

Many services from banks to healthcare utilize SMS as a main way of communicating with end-users. many rely on dynamic numbers.

Moreover, spoofing SMS messages is not that hard.

Messaging apps whether it is SMS or alternatives like whatsapp, telegram etc. will always offer a powerful vector to infect devices.

Re: Apple iMessage Zero-Click Hacks

#22

A small way to reduce attack surface - have iMessage just setup for your iCloud email address instead of phone number. Phone numbers are becoming increasingly useless. > In fact, Citizen Lab researchers and others suggest that Apple should simply provide an option to disable iMessage entirely. There's a checkbox in Settings > Messages that does exactly this? It seems strange they published this.

whatsapp doesn't rely on SMS protocols nor does it rely solely on phone numbers but is still being exploited quite often.

Instant-Messaging = Worthy target for exploits.

Just like web-browsers get exploited after years of patching.

Re: Apple iMessage Zero-Click Hacks

#23

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...

Well I would dare to say iMessage isn't the biggest target to convert to Rust.

At the end of the day, it is still an app with app level permissions, sandbox etc.

Kernel\Kernel modules are far more likely to be written as they allow for vastly more access than an app.

Re: Apple iMessage Zero-Click Hacks

#24
post #16

Wouldn’t be not parsing incoming media unless it’s for someone from contact is a first step that can reduce largely the thread ? So it will stay the same for people in your contact list but a new touch to load for message from unknown person

That might sound good in theory by in practice it's unlikely to go well(by default). Many services from banks to healthcare utilize SMS as a main way of communicating with end-users. many rely on dynamic numbers. Moreover, spoofing SMS messages is not that hard. Messaging apps whether it is SMS or alternatives like whatsapp, telegram etc. will always offer a powerful vector to infect devices.

I think banks don't use inline media in their messages too often.

Re: Apple iMessage Zero-Click Hacks

#25

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 the plist serialization attacks that end up coding for esoteric classes that contained various bugs.

Re: Apple iMessage Zero-Click Hacks

#26
post #20

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

Aren't these making it past BlastDoor, written in Swift?

Swift has e.g. UnsafePointer if you want to work more directly with memory. Presumably if BlastDoor uses them to work directly with memory then it could still be vulnerable, though I am not sure because I am not very familiar with them. If I was excited about pointers I wouldn't be using Swift...

Re: Apple iMessage Zero-Click Hacks

#27
post #16

Wouldn’t be not parsing incoming media unless it’s for someone from contact is a first step that can reduce largely the thread ? So it will stay the same for people in your contact list but a new touch to load for message from unknown person

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

Re: Apple iMessage Zero-Click Hacks

#28

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...

Apple had job postings last year looking for Rust developers to rewrite a service that was written in C so it's not without precedent. Job posting links are dead now, but there was a reddit thread about it: https://old.reddit.com/r/rust/comments/fkngza/apple_hiring_r...

A more fresh job posting from Apple: https://old.reddit.com/r/rust/comments/ou5szr/official_rrust...

Also: https://jobs.apple.com/en-us/search?search=rust&sort=relevan...

Re: Apple iMessage Zero-Click Hacks

#29

A small way to reduce attack surface - have iMessage just setup for your iCloud email address instead of phone number. Phone numbers are becoming increasingly useless. > In fact, Citizen Lab researchers and others suggest that Apple should simply provide an option to disable iMessage entirely. There's a checkbox in Settings > Messages that does exactly this? It seems strange they published this.

iCloud isn't end to end encrypted for the most part - anyone security conscious should be avoiding iCloud in the first place.

Re: Apple iMessage Zero-Click Hacks

#30

How do Zero click hacks work? Does iMessage accept arbitrary code that it can execute?

Depends on the hack but the majority seem to be from parsers for various formats, from images, to unicode and text data etc...

A message has to be able to display so many different types of content. A flaw in any one of those could be exploited. Combine a bunch of flaws together and you suddenly can do quite a bit.

Post reply on HN