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

A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

331–340 of 360 posts

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#331

Post by dreamcompiler »

optymizer wrote: post #320
dreamcompiler wrote: post #160

This is quite clever, but fundamentally it's only possible because of a buffer overflow. If the JBIG decoder had been written in Rust (just to cite one example of a language safer than C), this would have been impossible. Use dumb languages, pwn valuable prizes.

As much as I'd like to agree with you, the real reason this is happening is because humans wrote the code and humans make mistakes. And even if you rewrite all of the software in Rust, it'll still have exploitable bugs. Does it matter if it's a buffer overflow or a rusty pan, if the end result is someone reading your device's memory?

Since the first Fortran compiler one of the basic tenets of computer programming has been that the computer itself should help the human programmer express his/her ideas and help the human avoid basic accounting mistakes.

C doesn't do the latter. Blaming the human programmer for stupid accounting mistakes is misplaced. The human's mistake was in choosing a bad language.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#332

Post by nightpool »

walrus01 wrote: post #133
bscphil wrote: post #131

Earlier quoted context omitted.

No, just have the server reject anything at the /SendMessage endpoint over a certain size; presumably the client is resizing / recompressing images to hit a specific target.

there is no 'server' in a signal client-to-client link except as a directory server for the clients to find each other

This is not true. The server in the Signal protocol is responsible for message storage and delivery, just in a way where it's hard to associate individual message payloads with individual users (except by IP address, of course).

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#333

Post by onphonenow »

mcculley wrote: post #315
onphonenow wrote: post #242

Earlier quoted context omitted.

Exactly. This escape is technically quite cool frankly in terms of some creativity. That said, my own view is that messages from untrusted contacts should be straight ascii, parsed in a memory safe language with no further features until you interact (ie, write back etc).

Safeguards should be applied uniformly to all senders. A trusted sender could have been already exploited.

It's this attitude that is diminishing our security posture. Users want gifs, they want shared locations, they want heart emojies, they want unicode.

The fact that you force EVERY user you interact with to have them same treatment is the problem. Some people, I left into my house unsupervised. Some as guests. Some I don't let in at all.

We need to start modeling this approach online more.

I don't think you understand how far users will go to work around safeguards if they interfere with their daily life.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#334

Post by onphonenow »

snovv_crash wrote: post #171
onphonenow wrote: post #166

Earlier quoted context omitted.

Right, and they get there of a decomp pass on totally untrusted input over the network. This is why it's so crazy that apple has this huge attack surface. My own suggestion. Ascii only messages if contact is not in address book or is a contact you've communicated with in your message history (however long you keep that) up to 1 year. Once you reply these untrusted saudi contacts can send you the gif meme's.

"Hello this is the state police, your mother just got in a car accident, please respond"

The "police" already email and call me about my overdue IRS bill and my imminent arrest. I ignore all that crap.

Never interacted, maybe ascii only. Interacted, allow unicode and some other features (basic emojies? / photos?). Full contact? Allow the app integrations, heart sensor, animated images, videos etc.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#335

Post by mcculley »

onphonenow wrote: post #333
mcculley wrote: post #315

Earlier quoted context omitted.

Safeguards should be applied uniformly to all senders. A trusted sender could have been already exploited.

It's this attitude that is diminishing our security posture. Users want gifs, they want shared locations, they want heart emojies, they want unicode. The fact that you force EVERY user you interact with to have them same treatment is the problem. Some people, I left into my house unsupervised. Some as guests. Some I don't let in at all. We need to start modeling this approach online more. I don't think you understand…

> Users want gifs, they want shared locations, they want heart emojies, they want unicode.

I want all of those things. I use them every day. I don't trust any of my contacts to not have an infection.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#336

Post by UncleMeat »

lmm wrote: post #274
olliej wrote: post #225

Earlier quoted context omitted.

integer overflow is UB because on some architectures it was trapping. In practice for the last 30+ years the default behaviour has been non-trapping. So much so that making it trapping would break vast amounts of software that depend on it, so you can't change the general case behaviour in C, C++, etc, or "safe" languages like Java, C#, etc. Newer languages do recognize this and make trapping the default behaviour, b…

> In practice for the last 30+ years the default behaviour has been non-trapping. So much so that making it trapping would break vast amounts of software that depend on it, so you can't change the general case behaviour in C, C++, etc You can change it in C and C++, since the current behaviour is undefined i.e. give control of your computer to hackers. GCC and Clang should make -ftrapv the default. They won't, becaus…

You can change it to be trapping behavior, but doing so is problematic for architectures that cannot detect overflow at all of the supported widths in hardware because the software checks are slow.

Unfortunately (IMO), C and C++ has a sizable community that is unwilling to accept pessimizing behavior for various atypical architectures. This is not unreasonable, but it hugely limits the ability of the language to make decisions that work great for the 99%ile case.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#337

Post by ASalazarMX »

sterlind wrote: post #145
earthscienceman wrote: post #136

Earlier quoted context omitted.

Which we have a descriptive word for: unethical. The colorful word would be: disgusting

"When the rockets go up, who cares where they come down? That's not my department, says Werner von Braun." ~ Tom Lehrer

"Don't say that he's hypocritical, Say rather that he's apolitical"

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#339

Post by markus_zhang »

joe_guy wrote: post #237
dylan604 wrote: post #198

Earlier quoted context omitted.

"I found a 3rd party library that uses eval, so we just send it code we want to run and...boom. We're in." "I found a popular chat app that after install leaves a tool with full sudo privileages behind for us to take advantage of located clickityclickity... here. We're in." Sometimes, it can be even more pedestrian sounding. Hackers don't always have to be clever if other people are absolutely dumbasses before their…

To be clear, what this exploits is nothing like what you've mentioned. The article does a very good job of describing the relevant parts of the image format. They built a VM inside of an images single pass decompression route. I'd highly recommend reading the article. This is just one of the exploits in a very large chain. To quote some of the nations top security researchers: > Based on our research and findings, we…

This is really piece of artistic work. A bit crazy to think out of the box and I'm jealous lol.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#340

Post by markus_zhang »

saagarjha wrote: post #143
MayeulC wrote: post #128

Earlier quoted context omitted.

> Historically the jump from overflow to RCE was much much shorter. Not really. I am about to read the article, but it sounds like return-oriented programming[1] chaining "gadgets" that are small bits of existing code that you can re-purpose into executing arbitrary code by manipulating the stack. Extremely common exploitation technique, even if not trivial. Who said an exploit or RCE was trivial to exploit? Edit: I…

ROP chains are similar in spirit but typically created by hand and thus not all that long (several dozen steps, at most). Creating a 70,000 step program via a Turing tarpit is very interesting.

I wonder how they test the code? Maybe they can write a meta VM using a testable environment(e.g. in C) and transpile it into the instructions that library uses?
Post reply on HN