Live data from Hacker News

Apple iMessage Zero-Click Hacks

wired.com

31–40 of 156 posts

Re: Apple iMessage Zero-Click Hacks

#31

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.

Some Apple devs still seem to love C and Obj-C (at least the ones my former employer worked with directly) and hate on Swift. Both Swift and Rust can be written to a much higher standard where the language protects you from stupidity, but only if you give up the past and use them. While you can write pretty good C-ish code (i.e. Linux), its far too easy to slip up once and the language does nothing to save your ass.

Some of Apple's OS code is pretty ancient. Switching to Swift or Rust is not necessarily a panacea if you call too many OS routines still in C-ish.

Re: Apple iMessage Zero-Click Hacks

#32

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…

As a certified member of the Rewrite It In Rust (RIIR) Reaction Force, let me answer this by saying that it’s very, very hard to get the software right, even the second time, and RIIR trades one set of unknowns for another. There are also a huge number of people who are convinced that Rust is a fad, or that C is good enough, or whatever. The same people who swore they could outbrake ABS decades ago. They do not want to learn a new, hard thing, and Rust can be hard at first.

Re: Apple iMessage Zero-Click Hacks

#33

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

Usually by exploiting holes in some code that does parsing, e.g. for images. Here [1] is a nice write-up. [1] https://googleprojectzero.blogspot.com/2020/04/fuzzing-image...

Similarly, homebrew on the PSP exploited libjpeg or libtiff, so this is one of those vectors that we're still dealing with 16 years later.

Re: Apple iMessage Zero-Click Hacks

#34
post #2

I turned off imessage. I seem to be under attack lately. 3-4 times a day random links sent from gmail addresses or unknown phone numbers to imsg with sketchy looking links in them.

Can you war-dial attack with these? Seems like it would be super easy for a script kiddie to just start at 111-111-1111, send message, increment by 1, repeat. Maybe narrow it down to valid area codes and what not, but seems like a super low budget thing to do.

Re: Apple iMessage Zero-Click Hacks

#35

Earlier quoted context omitted.

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.

Some Apple devs still seem to love C and Obj-C (at least the ones my former employer worked with directly) and hate on Swift. Both Swift and Rust can be written to a much higher standard where the language protects you from stupidity, but only if you give up the past and use them. While you can write pretty good C-ish code (i.e. Linux), its far too easy to slip up once and the language does nothing to save your ass.…

I agree. Swift is a nice language, compared to the alternatives.

I have a few months experience in it, and I can definitely agree that if you're writing Swift-only, it's very nice. The emphasis on values, and value semantics is definitely a differentiator from most other languages.

However, anytime you have to use/interop with an older API designed for Obj-C (for example, AVFoundation), it's much more of a pain. Effectively, you're writing Obj-C in Swift.

If someone is insisting on Obj-C instead of Swift in 2021, I would attribute it to a form of a Stockholm Syndrome. Many people form psychological bonds with whatever they are familiar with.

Re: Apple iMessage Zero-Click Hacks

#36
post #9

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.

SMS is also exploitable though, right (Both types of messages go through Messages.app)? And you can't disable SMS entirely I don't think.

> you can't disable SMS entirely I don't think

Buy a data-only subscription, and use Google Voice or some sort of PBX powered app to still be able to receive regular phone calls.

Preferably I’d want a really basic voice only, open source PBX powered app for iOS that I could use. Then I could get me a data-only plan and SIM.

Caveat: I still need Norwegian BankID to work with my SIM though. I dunno if any of the data-only plans available in Norway support BankID, or if you need a regular subscription like I have now in order to use that.

Re: Apple iMessage Zero-Click Hacks

#37

Earlier quoted context omitted.

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…

As a certified member of the Rewrite It In Rust (RIIR) Reaction Force, let me answer this by saying that it’s very, very hard to get the software right, even the second time, and RIIR trades one set of unknowns for another. There are also a huge number of people who are convinced that Rust is a fad, or that C is good enough, or whatever. The same people who swore they could outbrake ABS decades ago. They do not want…

Haha, love the ABS analogy!

Re: Apple iMessage Zero-Click Hacks

#38

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.

Unless someone applies the squeaky wheel rule. The thing causing everyone to look at you gets pushed to the top of the list.

Re: Apple iMessage Zero-Click Hacks

#39
post #20

Earlier quoted context omitted.

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

It is highly unlikely BlastDoor is using much of those, except when interacting with system frameworks.

Re: Apple iMessage Zero-Click Hacks

#40

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…

Objective-C can run into other issues, though: NSSecureCoding exists for a reason ;)
Post reply on HN