Hacker News Reader

Comment by usmannk | Hacker News Reader

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.

View on HN

That reads like some handwavy explanation of a hack in a movie scene...

"Now I just have to embed a 64-bit computer architecture into my compression algorithm and... boom. We're in."

Then you can "Enhance".

https://www.youtube.com/watch?v=Vxq9yj2pVWk

Joking aside, this does illustrate the "magical" properties of technology to the layperson. As a corollary, failure modes end up quite suprising and hard to reason about without a certain amount of proficiency in these technologies.

Enhancing works with trained AI these days

Maybe not for evidence collection, but for pleasing a human being to go follow a lead sure

>Maybe not for evidence collection,

Kyle Rittenhouse was possibly almost convicted due to "enhance with AI".

Bring it up with the appeals court in the event it occurs, unless you run out of money. Dont run out of money.

I've seen some examples of this. It's very clearly trained on a white-male dataset.

I've also seen it "enhance" an image of a resistor into a human face.

I don't care how much AI you have, you can't add back data that wasn't in the original image. The best you can hope to do is get a vague approximation, and you must have a very, very good (comprehensive) training dataset for that to be remotely viable.

The premise of the technology is not adding more information to the image. But rather realizing that the image may have a description that is a lot smaller than its file size suggests; then it becomes a matter of rendering it using world-aware encodings. The resolution may appear higher but it is actually a filtration of the original data. And there’s nothing to say that simply because the current technology is overfitted to their present-day datasets, that such a filter (that is actually useful for common images, or enhancement by leveraging known/ few-shot other examples consisting of the same target object) cannot exist.

> It's very clearly trained on a white-male dataset.

TBF the Beatles look amazing in the Peter Jackson documentary, though the original material was shot on 16mm.

There is a world of difference upscaling something digital, and something analog. 16mm film actually does contain more information than could be shown with the original film. We have better scanning techniques today that can extract that information.

Upscaling something digital, does require creating information out of thin air, on the other hand.

Well, that and the explanation is missing the details. Conceptually being able to construct something like that from XOR and NOT primitives is stuff from undergrad computer engineering curriculum. But it's certainly a respectable feat to find this combination of compression format and the vulnerability therein of all the supported formats, and think to apply it like this.

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

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 assess this to be one of the most technically sophisticated exploits we've ever seen, further demonstrating that the capabilities NSO provides rival those previously thought to be accessible to only a handful of nation states.

This has nothing in relationship to eval().

I'm thinking you're missing the larger idea. The whole point is that while these "geniuses" did something really "impressive" and difficult, there are just as really not-impressive and not-difficult things found in the wild that have caused problems as well.

Why bring that up? It is something everybody knows and it adds nothing to this conversation.

It's called counterpoint. It was actually found interesting by several people, but you can have your opinion that you don't find it intersting. It actually did add to the conversation as there were multiply replies to it. Your comment about it is the thing that doesnt really add to anything.

Yeah. Even I know about eval. I'm just happy Google and Apple actually care about security unlike the 2000s companies and can rival the smartest hackers to keep my phone safe!

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

It reminds me about Nand to Tetris course https://www.nand2tetris.org

Its amazing how they took a buffer overflow and ran with it to create a whole turing complete machine. Its mind boggling how complex these exploits can be, no wonder they sell for millions

It also demonstrates how much more work there is after “buffer overflow” until you get to RCE.

Now - that is a big change.

Historically the jump from overflow to RCE was much much shorter.

Still the iMessage attack surface is just massive and running in an unsafe language kind of crazy?

> 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 was a bit quick to dismiss. The technique is certainly interesting, although the article doesn't go into the details of how the control flow is handled and where that register is stored. However, I'd like to point out that ROP is quite complex on its own, as it's kind of like using a computer with an arbitrary instruction set that you have to combine to create higher-level functions, hence my original confusion.

[1] https://en.wikipedia.org/wiki/Return-oriented_programming

Suffice it to say, this exploit was not simply chaining gadgets.

Right, my bad. I now read the article, the technique is intriguing, but I can't say much more for lack of details!

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.

> 70,000 step program

My initial assumption was that they would compile a program, take the binary output as an image and JBIG2-compress it, as I don't really get how they would use the result of the binary operations to branch to different code. Reading the article a bit more, I think they can loop multiple times over the area, by changing w, h and line dynamically over each pass, which would give them some kind of basic computer. That part is still unclear to me, but that would indeed be a lot more impressive.

There are no details on how control flow is handed over to the program either, so it's possible that they loop multiple time over the scratchpad (1 loop = 1 clock cycle roughly), especially if the memory area is non-executable, and they have one shot at computing a jump pointer.

In any case, they can probably copy arbitrary memory addresses into the new "scratchpad" area to defeat ASLR (we'll see in part 2).

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.

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"

[calls phone number]

In the US if something serious like this happens the police will physically notify the next of kin of it, not send you a text.

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.

Ah yes, let’s just force ASCII so that anyone using a language that’s not English has to suffer.

> […] 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 toolchain? The armv8.3 authenticated pointers have been invented to preclude this from happening, but that is not the case with the exploit.

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.

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.

I think what he means with historically is before ASLR, DEP, and other mitigations, where a buffer overflow meant you can simply overwrite the return pointer at ESP, jump to the stack and run any shellcode. Mitigations have made exploitation much, much more complex nowadays. See for example https://github.com/stong/how-to-exploit-a-double-free

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.

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

> running in an unsafe language kind of crazy?

It sounds like their first step in remediation was to move the GIF copy operation into the BlastDoor sandbox, which is written in Swift.

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.

absolutely brilliant, genius work.

I was confused about how they got the thing to run for an unbounded amount of time, but I guess they probably have the final operation at the end of a "processor cycle" be to overwrite the next SegRef so that it loops back to the current SegRef.

I'd love to see the thing in more detail - what the shellcode looks like, how the CPU was designed, everything.

a scummy company but such transcendental brilliance..

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

https://github.com/google/wuffs

the problem is, this is an ancient PDF feature from the 90s that nobody has time to write and debug

so they just took an open source parser and slapped it in there

it’s hard to rewrite PDF parsing to a new language so that everything still works. Especially those weird features that people forgot about.

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 the shellcode, and that wouldn't lend itself to a processor-like design - it'd just be too big.

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.

Basically anything that exceeds the regular category is risky and difficult to secure. See weird machines / langsec. This is a prime example.

Well, when combined with an integer overflow at least.

Technically it's not a buffer overflow; it's an integer overflow bug.

Reply on news.ycombinator.com