NSO group iPhone zero-click, zero-day exploit captured in the wild • Hacker News Board

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#831

Post by astrange » Sat, Sep 09, 2023, 12:33 AM UTC

runeks wrote: post #734

astrange wrote: post #640

Earlier quoted context omitted.

"Manually copy data into a memory buffer" is pretty vague… try "writing a DSP function that does qpel motion compensation without having to calculate and bounds check each source memory access from the start of the image because you're on x86-32 and you only have like six GPRs". Though that one's for video; images are simpler but you also have to deploy the code to a lot more platforms.

Why would an iPhone be running x86-specific code? I don't dispute that these optimizations may have been necessary on older hardware, but I think the current generation of Apple CPUs should have plenty of power to not need these micro optimizations (and the hardware video decoder would take care of this anyway).

> Why would an iPhone be running x86-specific code?

The same codebase has to support that (since there's Intel Macs and Intel iOS Simulator), and in this case Apple didn't write the decoder (it's Google's libwebp). I was thinking of an example from ffmpeg in that case.

> and the hardware video decoder would take care of this anyway

…actually, considering that a hardware decoder has to do all the same memory accesses and is written in a combination of C and Verilog, I'm not at all sure it's more secure.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#832

Post by astrange » Sat, Sep 09, 2023, 12:33 AM UTC

sudosysgen wrote: post #218

astrange wrote: post #207

Earlier quoted context omitted.

Almost all people don't want to or aren't capable of implementing image codecs, the safer languages aren't fast enough to do it in, and the people who are capable of it don't want to learn them.

I'm sure that given a middling-to-Google (say, 30k) bounty it would be done. I'd give it a shot, anyways.

Give it a try, it's fun. But between writing Huffman decoders and IDCTs and reading the specs in a 1000 page Word document, it's a lot to learn.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#833

Post by insanitybit » Sat, Sep 09, 2023, 12:52 AM UTC

astrange wrote: post #830

insanitybit wrote: post #820

Earlier quoted context omitted.

I don't believe you, frankly. I don't believe that Google makes breaking changes to existing image formats often.

They already did - WebP added a lossless mode and VP8 was updated to VP9. Though the same may happen to JPEG; it always had 10-bit and 12-bit modes but most decoders don't support them. (Not sure if they can decode it as 8-bit or not.)

Are those breaking changes? I'd assume that a decoder would continue to work, just would not support the lossless mode/ VP9.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#834

Post by s3p » Sat, Sep 09, 2023, 1:49 AM UTC

Obscurity4340 wrote: post #234

Its super interesting to me how much its emphasized that you shouldn't use Lockdown Mode unless you are a journalist or otherwise in direct palpable danger. They really do try to talk you out of it. Its curious, because there's very little difference in functionality (as experienced by the user) other than disabling a lot of Apple nonsense from running in the background expanding your attack surface. And everybody pa…

> They really do try to talk you out of it.

Who? Apple? I can't find any statements from them begging us not to use it. It's also a dumb argument since they can just --not-- release the feature if they don't want us to use it.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#835

Post by Hackbraten » Sat, Sep 09, 2023, 2:49 AM UTC

Dylan16807 wrote: post #819

Hackbraten wrote: post #782

Earlier quoted context omitted.

> And how did you screw up length x width x 4? There’s a million ways to screw that up. People botch SCM merges. People are hungover. People are distracted. People are tired. People are heartbroken. People are going through divorces. People have parents dying. People forget numbers. People make copy-paste mistakes. All the time. > The sandboxed process doesn't have any way to exfiltrate data. You can abuse it to gain…

> People make copy-paste mistakes. All the time. But if you do that every image looks wrong and it's vanishingly unlikely to get into a release. > You can abuse it to gain a (known-page-offset) write primitive in the other, non-sandboxed process to which the buffer is also mapped. There's no reason to have the memory mapped into both processes at once, and you can't exploit the bytes you write without a real vulnerab…

> But if you do that every image looks wrong and it's vanishingly unlikely to get into a release.

The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted.

> Since it's a one-shot write into the buffer, if your intent is using it as an exploit step then you might as well encode an actual image with your exploit-assisting bytes.

The assumption was that the code tries to clean up the buffer immediately after use.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#836

Post by stephenr » Sat, Sep 09, 2023, 3:26 AM UTC

kn0where wrote: post #818

stephenr wrote: post #523

Earlier quoted context omitted.

I'm fairly certain that "text to email" is a feature of MMS - I've used it a few times years before iPhones were around. I don't remember if MMS is enabled by default in iOS but theres a toggle to disable it, and realistically there's very minimal real world use-case for MMS these days.

Yes, it’s an MMS feature. But iMessage makes it way too easy to “text to email” inadvertently when you start a group chat with some non-iPhone users. MMS sucks but it’s the universal way for iPhone and Android users to communicate without needing everyone to be on the same third-party messaging platform like WhatsApp. In my US-centric personal experience, there is no universally accepted messaging app you can be cert…

The universal option is SMS.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#837

Post by astrange » Sat, Sep 09, 2023, 3:40 AM UTC

insanitybit wrote: post #833

astrange wrote: post #830

Earlier quoted context omitted.

They already did - WebP added a lossless mode and VP8 was updated to VP9. Though the same may happen to JPEG; it always had 10-bit and 12-bit modes but most decoders don't support them. (Not sure if they can decode it as 8-bit or not.)

Are those breaking changes? I'd assume that a decoder would continue to work, just would not support the lossless mode/ VP9.

It will work on old files (since they've already been encoded) but not on new files with the same file extension, and not on, say, YouTube.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#838

Post by Dylan16807 » Sat, Sep 09, 2023, 4:00 AM UTC

Hackbraten wrote: post #835

Dylan16807 wrote: post #819

Earlier quoted context omitted.

> People make copy-paste mistakes. All the time. But if you do that every image looks wrong and it's vanishingly unlikely to get into a release. > You can abuse it to gain a (known-page-offset) write primitive in the other, non-sandboxed process to which the buffer is also mapped. There's no reason to have the memory mapped into both processes at once, and you can't exploit the bytes you write without a real vulnerab…

> But if you do that every image looks wrong and it's vanishingly unlikely to get into a release. The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted. > Since it's a one-shot write into the buffer, if your intent is using it as an exploit step then you might as well encode an actual image with your exploit-assisting b…

> The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted.

I could argue this more but it doesn't matter, that was just a little tangent, getting the size wrong will not let anything out of the sandbox.

> The assumption was that the code tries to clean up the buffer immediately after use.

Cleaning up would be removing the mmap. How are you going to exploit that? Your scenario is not very clear.

I think you're going for a situation where the sandboxed process can write to data in the host process outside the buffer? In a general sense I can imagine ways for that scenario to occur, but I can't figure out how you could get there via mmapping a buffer badly. A buffer mmap won't overlap anything else. If the mmap is too small then either process could read past the end, but would only see its own data (or a page fault).

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#839

Post by jmprspret » Sat, Sep 09, 2023, 5:40 AM UTC

saagarjha wrote: post #547

callalex wrote: post #401

Earlier quoted context omitted.

There is even precedent for doing this seamlessly: the Apple Mail client will not render media from unknown senders without user confirmation. iMessage should have the exact same behavior for the same reasons. It’s frustrating to watch greedy project managers re-learning the exact same lessons that a previous generation already learned the hard way, especially when they all work in the same building.

This is how Lockdown Mode works.

This should be the default. It is the default on apple mail from what I'm reading, so why not the I message app?

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#840

Post by Hackbraten » Sat, Sep 09, 2023, 7:02 AM UTC

Dylan16807 wrote: post #838

Hackbraten wrote: post #835

Earlier quoted context omitted.

> But if you do that every image looks wrong and it's vanishingly unlikely to get into a release. The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted. > Since it's a one-shot write into the buffer, if your intent is using it as an exploit step then you might as well encode an actual image with your exploit-assisting b…

> The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted. I could argue this more but it doesn't matter, that was just a little tangent, getting the size wrong will not let anything out of the sandbox. > The assumption was that the code tries to clean up the buffer immediately after use. Cleaning up would be removing the…

> Cleaning up would be removing the mmap. How are you going to exploit that? Your scenario is not very clear.

If a buffer is going to be reused across calls, then cleaning after use is not the same thing as unmapping. One example for cleaning up a buffer after use would be zeroing.

If there's a bug in the calculation for the amount of zeroing needed, then leftover attacker-controlled data can bleed back from the sandboxed into the unsandboxed process and survive beyond the current transaction (because the code failed to zero the buffer correctly after use).

In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer. That data may not be very useful on its own, because it's still confined to the mmapped buffer. But it's now relatively well protected from reuse (until the next decoding task arrives).

That's plenty of time to do shenanigans. For example, you can combine it with an (unrelated) stack buffer overflow that may exist in the unsandboxed process, harmless on its own but more powerful if combined with an attacker-controlled gadget in a known location.