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

201–210 of 360 posts

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

#201

Post by azakai »

pornel wrote: post #197
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.

This case is easy. No need to rewrite: deleted code is even safer than Rust. Apart from Rust, Wuffs is also a good candidate for codecs: https://github.com/google/wuffs/blob/main/doc/wuffs-the-lang... Too bad that Swift isn't that good for low-level codecs, so a Swift rewrite of Messages couldn't remove C dependencies.

If the code can't be deleted then an alternative to rewriting is to sandbox it like Firefox recently started to do with wasm. That would have kept any exploit in the sandbox - let them have fun in there with that 70,000 step program where it can't touch anything...

Sandboxing using wasm has around 10% overhead, so a full rewrite might end up running faster. But recompiling the code takes less time and effort and will not introduce new bugs, so it's a useful option too.

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

#202

Post by meibo »

terhechte wrote: post #186
meibo wrote: post #175

And still, in 2021, after so many exploits, realizing the futility of trying to fix these bugs and adding their "blast door" process, some Apple dev calls image parsing code where it doesn't belong. The people that are supposed to maintain the element of the OS that has been abused most by nation states do not know the internal APIs they are working with, even just to display looping GIFs. This negligence is killing…

How do we know this code was written in 2021? GIF support was added to iMessage (I think) in 2016 or 2016; I couldn't find an exact date.

That's a fair point, but doesn't change the fact that it remained there after the code review that was surely(?) made after implementing blast door. Especially for image parsing APIs, considering they've always been the brittle part in the iMessage pipeline.

Not sure how Apple dev machines look like, but usually I can find stuff like this with a well written grep or a shell script and my API definition, if I'm not sure that I caught everything while refactoring. The codebase might be massive but the team should be sizeable enough to handle it.

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

#203

Post by bialpio »

attack-surface wrote: post #30
NikolaeVarius wrote: post #24

Earlier quoted context omitted.

Why did you create a brand new account for the sole reason of posting a somewhat low information post.

Go easy on me, I'm new here. I plan to comment a lot more as time goes by. My comment is purely anecdotal. I'm not saying `everyone now has malware`, just stating that classes of attacks can be killed by doing basic security like principle of least privilege & sandboxing (Android and Apple probably already do it, but then how are these attacks possible?)

I think the part of the article that touches on this is:

"(...) iMessage calls the following method in the IMTranscoderAgent process (outside the "BlastDoor" sandbox), (...)"

Looks like they have been decoding GIFs outside of the sandbox, which has been addressed later:

"Apple inform us that they have restricted the available ImageIO formats reachable from IMTranscoderAgent starting in iOS 14.8.1 (26 October 2021), and completely removed the GIF code path from IMTranscoderAgent starting in iOS 15.0 (20 September 2021), with GIF decoding taking place entirely within BlastDoor."

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

#204

Post by codedokode »

I think that allowing overflows to go unnoticed is a mistake. Overflow on addition should cause an exception by default. It should be easy to implement in hardware and as it is UB in C, correctly written programs wouldn't break.

For example, imagine if you are counting money and because of the overlow millions turn into several cents.

Another evil thing is indirect jumps. They should be implemented using an index into a jump table.

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

#205

Post by flatiron »

vsareto wrote: post #157
shmatt wrote: post #109

NSO get way too much credit/dramatization these days. They are mostly 2 things * a shiny UI for customers * a bank of 0-days Those 0-days could be found in house, could be brought in from a new employee copying a previous employer, or could simply be purchased. Most people in the IDF understand when a great security researcher leaves 8200, the company they move to will probably have some of their secrets, theres real…

I think you get credit for having a bank of actual zero days, self-discovered or not Trying to trivialize the threat they pose only helps NSO Plus, "willing to sell to nations with bad human rights records" should be on that list

“All the us army is is a bunch of tanks and planes”

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

#206

Post by orlp »

codedokode wrote: post #204

I think that allowing overflows to go unnoticed is a mistake. Overflow on addition should cause an exception by default. It should be easy to implement in hardware and as it is UB in C, correctly written programs wouldn't break. For example, imagine if you are counting money and because of the overlow millions turn into several cents. Another evil thing is indirect jumps. They should be implemented using an index int…

Integer overflow is not UB in C, only signed integer overflow. Unsigned integer overflow is defined to be modulo 2^w. And there are plans in C2x or C23 IIRC to make signed integer overflow well-defined in terms of two's complement too.

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

#207

Post by zamadatix »

bscphil wrote: post #131
sterlind wrote: post #107

Earlier quoted context omitted.

then that offers no security at all, since an attacker could use a hacked client. unless clients also refuse to receive anything but one, very well-validated, format, so that sending anything funky would be futile.

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.

Messages support arbitrary files up 100 MB. Images are resized or compressed for user experience on different devices. The server doesn't know what's in a message.

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

#208

Post by tialaramex »

MarkSweep wrote: post #140
usmannk wrote: post #3

This is mind boggling. NSO used a compression format's instructions to create logic gates and then from there "a small computer architecture with features such as registers and a full 64-bit adder and comparator which they use to search memory and perform arithmetic operations", all within a single pass of decompression. Combine this with a buffer overflow and you've got your sploit.

Stop weird machines! http://langsec.org/occupy/

In this particular case:

If you are Wrangling Untrusted File Formats, you should be doing so Safely, using WUFFS.

You can't make this mistake in WUFFS. Your WUFFS image decoder might decode the image incorrectly, maybe Rudolph has a green or blue nose, maybe he's upside down or just a sea of noise, but it can't have a buffer overflow even if you screwed up really badly.

For example, any equivalent of the repeated addition numSyms += ((JBIG2SymbolDict *)seg)->getSize(); in WUFFS will get flagged, it clearly could overflow and WUFFS wants you to write code explaining how you're going to prevent that because overflows aren't allowed in WUFFS.

This leaves outfits like NSO with nothing much to attack. Sending me pictures of Rudolph with a green nose by "exploiting" a bug in my image decoder isn't very useful, unlike taking over my phone...

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

#210

Post by charcircuit »

xiphias2 wrote: post #105
ASalazarMX wrote: post #40

Earlier quoted context omitted.

If they solved P = NP, their first intention would be selling it to the highest bidder. NSO hackers are the digital equivalent of mercenary soldiers.

They don’t really have to, they can just mine Bitcoin by reversing SHA256 in polynomial time, inspect https messages to banks, or send Bitcoin to themselves by creating an ECDSA signature… or just set up a software as a service and have the biggest business in the world.

>they can just mine Bitcoin by reversing SHA256 in polynomial time

This wouldn't be faster than ASICs. The coefficients would be too big for it to be practical.

Post reply on HN