Live data from Hacker News

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

citizenlab.ca

311–320 of 886 posts

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

#312

Earlier quoted context omitted.

The article references Lockdown mode [0] which appears to be Apple's solution for this (and other) class of zero days. [0] https://support.apple.com/en-ca/HT212650

Lockdown mode means you're able to use less stuff. In this case the "pass" feature doesn't exist in Lockdown mode and that's the attack target AIUI. So, if most people don't use it (because less stuff works) then it can be "successful" statistically because maybe the attackers aren't targeting the stuff you're allowed to use and you don't get exploited. But this isn't a stable solution really. If Lockdown is populari…

The list is not arbitrary, but generally based on remote attack surface.

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

#313

Earlier quoted context omitted.

It does make iOS slightly more inconvenient, such as when adding each other on iMessage. And it severely reduces JavaScript performance in Safari. I think Apple wants to avoid making iOS feel slower or clunkier than Android. And zero-day spyware is usually targeted towards important individuals, not used for mass surveillance, so it indeed is a smaller risk to individual people. I'd prefer a third mode that compromis…

I’d settle for being able to toggle the individual controls (specifically iMessage attachments) instead of full lockdown mode.

YES! Current lockdown mode proposition of all-or-nothing is inconvenient.

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

#314
post #52
post #42

For anyone interested in learning more about the NSO group, I'd recommend this podcast episode: https://darknetdiaries.com/episode/100/

[flagged]

We bought a vassal state with highly competent people. They are generally independent in internal affairs and so NSO group would have nothing to do with the government.

But you're right, we don't need that one at all any longer. Someone once told me that Israel would align more closely with Russia if we did that, which is a laughable come back, like, okay? have fun with that.

Retracking the various forms of funding and defense contractor slush funds would be a simple step.

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

#315
post #70

Again a buffer overflow in image decoding, that sounds similar to the one from 2021 [1]. That one was wild, building a CPU out of primitives offered by an arcane image compression format embedded in pdf, to be able to do enough arithmetic to further escalate to arbitrary code execution! [1]: https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

I’m not much into security but I’ll never forget this one. Fascinating.

Somebody know articles like this on different exploits? What a great read!

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

#316

How many exploits has iMessage had now? Isn't it time we made first messages from all new contacts plain text only, and all other messages some very restricted subset rather than some crazy extensible system that isn't so different from ActiveX? And on top of that, maybe the whole app should run in a sandbox. And on top of that, perhaps it should all be a webview to give one more layer of protection.

Every process in iOS is run in a sandbox. That is why these exploits are so hard to come by.

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

#317

I find it interesting that most comments here are blaming the victim (Apple’s iMessage and by transitivity its users) rather than the aggressor (NSO and its users). How come NSO isn’t yet designated as a (cyber-)terrorist group worth hunting down and extinguishing?

[deleted]

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

#318

Earlier quoted context omitted.

If you show me software that's immune to advanced 0-days, I'll show you software that isn't usable.

That depends entirely on what the software needs to do. For image decoding in particular, you can put the software into an exceptionally restrictive sandbox, or use a language that builds in the same restrictions. No I/O. No system calls. Just churn internally and fill a preallocated section of memory with RGBA. The broader system will still have weaknesses, but it won't have this kind, and this kind keeps happening.

That's an awfully big preallocated array you have there. It would be pretty inefficient for that section of memory to be copied around, right? Let's map it into both processes. Also, image decoding is pretty hard, let's offload some of it to dedicated hardware. Of course, that hardware needs to have access to it mediated by the kernel. And the hardware needs to be able to access that shared memory, which was of course allocated correctly and the IOMMU setup was done correctly…

You see how even simple things are difficult to secure when they have to be implemented in practice?

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

#319

Earlier quoted context omitted.

How fast does iMessage image decoding need to be? And I mean this extremely rhetorically. The software launched along with the iPhone 4S. Going by geekbench, that CPU was 20-30 times weaker than a modern iPhone on a per-core basis. I know the screens on the new phones are 5x bigger, but there is plenty of room for that sandbox.

I'm guessing it's a shared systemwide decoder that happens to be exploitable in Message, but idk.

That's correct, it's the WebP parser.

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

#320

Earlier quoted context omitted.

That's needlessly defeatist and "it's so bad out there there's no point in trying" is a thought terminating cliché. We can and should improve development practises, mitigate vulnerabities (ASLR, WAFs, etc), isolate systems from each other, and model threats in a way that we know where and how to do those things. It's not easy but just moaning "everything sucks" isn't how to fix it.

Apple, Google, etc. have whole teams of talented people dedicated to doing exactly these types of things, and they undoubtedly help prevent many vulnerabilities from escaping the labs. Yet vulnerabilities are still created and exploited despite their best efforts. As long as software is created by imperfect humans, it will reflect the imperfections of its creators.

This is my take as well. If Apple and Google can't do it then what hope does anyone else have? The current paradigm is insecure and broken.
Post reply on HN