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

61–70 of 156 posts

Re: Apple iMessage Zero-Click Hacks

#61

Post by saagarjha »

stephencanon wrote: post #58
setpatchaddress wrote: post #47

Earlier quoted context omitted.

Yes, there are some people who simply prefer Objective-C, but you need to also realize that Swift is still not ready for system-level programming. Analysis tools aren’t ready; debugging basically means you go to printing variables to stderr and praying. The standard library defaults to crashing at runtime for simple float integer conversion bounds errors which you’d think would be caught statically with more thoughtf…

> The standard library defaults to crashing at runtime for simple float integer conversion bounds errors which you’d think would be caught statically with more thoughtful design. There are very real ways in which Swift isn't ready for systems programming, but this sure ain't one of them. - In C and C++, this doesn't trap, it's undefined behavior. Trapping is _always_ better than UB. Are C and C++ "not ready for syste…

One can make the argument that UB allows implementations flexibility on how they define overflow, allowing e.g. -fwrapv and trapping to be permissible based on what your desire is. But it's a fairly weak argument and doesn't detract from the rest of your points.

Re: Apple iMessage Zero-Click Hacks

#62

Post by stephencanon »

saagarjha wrote: post #61
stephencanon wrote: post #58

Earlier quoted context omitted.

> The standard library defaults to crashing at runtime for simple float integer conversion bounds errors which you’d think would be caught statically with more thoughtful design. There are very real ways in which Swift isn't ready for systems programming, but this sure ain't one of them. - In C and C++, this doesn't trap, it's undefined behavior. Trapping is _always_ better than UB. Are C and C++ "not ready for syste…

One can make the argument that UB allows implementations flexibility on how they define overflow, allowing e.g. -fwrapv and trapping to be permissible based on what your desire is. But it's a fairly weak argument and doesn't detract from the rest of your points.

Yeah, I used to think that, but compilers are already allowed to do whatever they want in non-standard modes. Defining the result wouldn’t prevent implementing fwrapv or trapv. (Also note that neither of these applies to float-int conversions, so let’s not pretend that either helps here).

Re: Apple iMessage Zero-Click Hacks

#63

Post by stephencanon »

saagarjha wrote: post #50
setpatchaddress wrote: post #47

Earlier quoted context omitted.

Yes, there are some people who simply prefer Objective-C, but you need to also realize that Swift is still not ready for system-level programming. Analysis tools aren’t ready; debugging basically means you go to printing variables to stderr and praying. The standard library defaults to crashing at runtime for simple float integer conversion bounds errors which you’d think would be caught statically with more thoughtf…

Swift is not ready, but it's not for those reasons. The real problem is that Swift needs a hefty runtime and is fairly slow due to excessive ARC traffic, plus it has no way of recovering from memory exhaustion. So you can't really use it in the kernel, but it's perfectly fine for writing system frameworks and daemons.

Realistically none of the commonly used systems languages have a mechanism to recover from memory exhaustion. Some pretend to, but if you actually try to use them, yeeeeech

The big missing features (from my perspective) are fixed-size arrays, placement allocation, and the ability to guarantee that no allocations or refcount operations occur in a marked critical section. There’s a lot of other stuff I would like to have, but those are the things I can’t live without.

Re: Apple iMessage Zero-Click Hacks

#65

Post by dgfitz »

dylan604 wrote: post #34
eyeball wrote: 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.

I hope that’s their starting point. My number has at least 1+ 0s in it. =)

Re: Apple iMessage Zero-Click Hacks

#66

Post by stefan_ »

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

You are talking about the same company that shoved their proprietary WiFi protocol full of holes straight into the kernel. Judging from the kind of messages it emits, the latter is a true masterpiece by the way.

Re: Apple iMessage Zero-Click Hacks

#67

Post by vlozko »

tyingq wrote: post #20
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?

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

The exploit targets existing C code that did image decoding and used CoreFoundation to handle data reads. Blast door is Swift-based and likely very memory-safe. What I’m curious about is where the limits of BlastDoor are that it couldn’t contain this particular attack. I’m under the impression that BlastDoor was built exactly for this type of attack.

Re: Apple iMessage Zero-Click Hacks

#68

Post by saagarjha »

stephencanon wrote: post #63
saagarjha wrote: post #50

Earlier quoted context omitted.

Swift is not ready, but it's not for those reasons. The real problem is that Swift needs a hefty runtime and is fairly slow due to excessive ARC traffic, plus it has no way of recovering from memory exhaustion. So you can't really use it in the kernel, but it's perfectly fine for writing system frameworks and daemons.

Realistically none of the commonly used systems languages have a mechanism to recover from memory exhaustion. Some pretend to, but if you actually try to use them, yeeeeech The big missing features (from my perspective) are fixed-size arrays, placement allocation, and the ability to guarantee that no allocations or refcount operations occur in a marked critical section. There’s a lot of other stuff I would like to ha…

Yeah, I agree, I'm just saying that Linus won't use it unless he feels like it gives him that "control" ;)

Re: Apple iMessage Zero-Click Hacks

#69

Post by RavlaAlvar »

coldcode wrote: post #31
raspasov wrote: post #17

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 can totally relate to people who love the simplistic of C, but ObjC? I couldn’t fathom why anyone would prefer this mess to Swift.

Re: Apple iMessage Zero-Click Hacks

#70

Post by hirako2000 »

hexa22 wrote: post #49
p49k wrote: post #48

Earlier quoted context omitted.

Data-only subscriptions can still receive SMS messages in my experience, you just can't send them.

And you still need them because some services only provide sms verification.

And we don't need those services. We just want them for convenience.

The data only plans is is good path to follow, it at least makes it more obvious each time a service clearly wants too much personal data.

Post reply on HN