A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution • Hacker News Board

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

#341

Post by markus_zhang » Thu, Dec 16, 2021, 7:36 PM UTC

sterlind wrote: post #101

inasio wrote: post #86

Earlier quoted context omitted.

It seems we're now at the point where anything Turing complete can be a vector. Wow...

this wasn't Turing-complete until they exploited it to make it so. JBIG2 executes arbitrary binary bitmap operations, but sequentially (no looping.) using the exploit they presumably found a way to send it into a loop, probably by overwriting the pointer to the next segment or something. theoretically I guess you don't need that, but you'd have to send a payload linear in size to the number of cycles expected to run…

This reminds me of the original story of Mel in which Mel managed to do similar things with assembly. Amazing stuffs and wish I had a chance to work with similar genius.

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

#342

Post by markus_zhang » Thu, Dec 16, 2021, 7:44 PM UTC

rodgerd wrote: post #146

nlh wrote: post #53

As other have commented, this is absolutely mind-bogglingly hard core. Kudos to the NSO group engineers who designed and built this (regardless of your allegiances and whether you like or dislike that they do this and whether it's objectively good or evil or somewhere in between, you have to admit that it's deeply technically impressive). Does anyone have a sense of who they sold this to and who used this particular…

> regardless of your allegiances and whether you like or dislike that they do this and whether it's objectively good or evil or somewhere in between, you have to admit that it's deeply technically impressiv Might as well praise German logistics circa 1940-1945.

German logistics that circa was actually pretty inefficient, big part why they failed to beat the opponents.

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

#343

Post by markus_zhang » Thu, Dec 16, 2021, 7:50 PM UTC

johndoughy wrote: post #108

ttul wrote: post #36

TL;DR - the ending of the post is all you need: “JBIG2 doesn't have scripting capabilities, but when combined with a vulnerability, it does have the ability to emulate circuits of arbitrary logic gates operating on arbitrary memory. So why not just use that to build your own computer architecture and script that!? That's exactly what this exploit does. Using over 70,000 segment commands defining logical bit operation…

They must have spent tons of engineering effort to create this virtual computer to act as their foundation for further exploits. They don't deserve any sympathy of course, but it must really suck that their foundation disappears immediately with the fixed vulnerability.

I actually think you can write and test a NAND gate solution in any external environment that is much easier for development and testing (say plain C on Linux),and then transpile it into any other turing complete arch. Actually this could be a really interesting project to work on: 1) Write a VM in C and 2) Write a transpile program for another turing complete arch.

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

#344

Post by jl6 » Thu, Dec 16, 2021, 8:08 PM UTC

So did xpdf get a new release to fix the overflow?

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

#345

Post by mderazon » Thu, Dec 16, 2021, 9:49 PM UTC

ChuckMcM wrote: post #122

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.

I read through this and my jaw dropped. Pretty amazing detective work and a really amazing exploit. Presumably you could run Doom on it :-). Sometimes I feel like it's hopeless but my brain cannot help but work on creating solutions to this sort of problem.

Indeed amazing and also very well written article.

I wonder how much time it took to develop, I assume the whole general programming language from NAND gates is not something they had to come up with from scratch.

Putting the pieces together though, that's a work of art

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

#346

Post by qalmakka » Fri, Dec 17, 2021, 4:34 AM UTC

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.

Even if this was properly written C++ this wouldn't have worked, i.e. if the authors had used a std::vector instead of a hodgepodge of new and malloc. Even if you had overflowed the integer and used it to reserve some capacity in a vector, calling `push_back` would have reallocated the vector instead.

Containers and move/by-value semantics in C++ inherently avoid a lot of stuff, it's sad seeing so many C++ developers do not actually know the language and instead stick with a "C with classes" that doesn't provide any extra security compared with C.

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

#347

Post by saagarjha » Fri, Dec 17, 2021, 11:57 AM UTC

jvolkman wrote: post #251

saagarjha wrote: post #219

Earlier quoted context omitted.

Perhaps you should’ve read my reply from when you asked this several months ago: https://news.ycombinator.com/item?id=28521664

Seems most users don't know about https://hnreplies.com/

I mean normally I’d let this slide but this user seems to not have any productive contributions other than this

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

#348

Post by saagarjha » Fri, Dec 17, 2021, 11:59 AM UTC

inkyoto wrote: post #244

saagarjha wrote: post #161

Earlier quoted context omitted.

iOS does not allow the modification or generation of new executable code (at least, it will not at this stage of an exploit). So they are likely creating a weird machine to patch various data and then redirecting control flow with the altered state by overwriting a function pointer.

> […] then redirecting control flow with the altered state by overwriting a function pointer . The analysis calls this out specifically: > Conveniently since JBIG2Bitmap inherits from JBIG2Segment the seg->getType() virtual call succeed even on devices where Pointer Authentication is enabled Which is disturbing. Was the code compiled for the arch64e architecture in the first place, or it is a bug in the LLVM compiler…

Pointer authentication cannot protect against all pointer substitutions, because doing so to arbitrary C++ code would violate language guarantees. https://github.com/apple/llvm-project/blob/next/clang/docs/P... is a good overview of which things can and can’t be signed because of standards compliance.

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

#349

Post by saagarjha » Fri, Dec 17, 2021, 12:01 PM UTC

markus_zhang wrote: post #340

saagarjha wrote: post #143

Earlier quoted context omitted.

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?

If I was them I’d test each part of the toolchain (which I assume is a high-level compiler of some sort to their RISC VM) independently, as you would for any component of this type. For the actual exploits itself it’s probably a regular debugger with facilities tailored to their VM.

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

#350

Post by albrewer » Fri, Dec 17, 2021, 5:14 PM UTC

mderazon wrote: post #345

ChuckMcM wrote: post #122

Earlier quoted context omitted.

I read through this and my jaw dropped. Pretty amazing detective work and a really amazing exploit. Presumably you could run Doom on it :-). Sometimes I feel like it's hopeless but my brain cannot help but work on creating solutions to this sort of problem.

Indeed amazing and also very well written article. I wonder how much time it took to develop, I assume the whole general programming language from NAND gates is not something they had to come up with from scratch. Putting the pieces together though, that's a work of art

They probably defined some microcode operations -> created a minimal assembly language -> wrote it in C -> hand-optimized the asm output -> compiled to "machine" code

All the steps are things you cover in a computer engineering degree (I think), but putting them all together in a tightly constrained environment (or even recognizing that the exploit can happen in the first place) takes a ton of skill, resources, and dedication.