Live data from Hacker News

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

citizenlab.ca

141–150 of 886 posts

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

#141
post #131

I appreciate that a solution is for people to update immediately. It really makes me wonder if my Android phones over the years have had 1-days exploited by the sheer incompetence of the ecosystem in updating phones. Not much confidence when you get an update with security patches from 2-3 months ago.

These exploits are highly targeted, they aren't just flying around hitting random devices.

Best way to secure your devices is to not be a target!

/s

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

#142
post #78

Earlier quoted context omitted.

Apple have a service which attempts to do this, BlastDoor. The issue here is feature surface area unrelated to GSM. My guess from the CVEs is that this exploit revolves around sending a valid Wallet/PassKit item attachment which has a malicious image. The payload is safely _deserialized_ by BlastDoor itself, but is then passed off to the PassKit framework which happily detonates it. IMO Apple should make a middle gro…

Loading anything other than text from unknown senders...

It pisses me off man. If someone sends you a link on iOS, you can't copy it without doing a long press that loads all the spyware on the website in a preview window

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

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

Which actually makes me more sympathetic to Chrome not (yet) adopting JPEG-XL. Don't get me wrong, I think JPEG-XL is a great idea, but to everyone saying "how can supporting another image format possibly do any harm", this is the answer.

Why not implement all image codecs in a safer language instead?

That would seem to tackle the problem at its root rather than relying on an implementation's age as a proxy for safety, given that that clearly isn't a good measure.

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

#144
post #132

Earlier quoted context omitted.

1) What does this topic have to do with Android? 2) EU politicians don't know about Android updates because they don't understand how SW works and most probably have iOS anyway. The only time they hear about tech is when some Joe Schmoe insults them on Facebook so they send the courts after Facebook to doxx that person and get Facebook to moderate and ban "hate speech" on their platform. All in a day's work. Granted,…

> Mr. CEO, can TikTok access my WiFi? That wasn’t a bad or mock-worthy question at all. TikTok’s app requests access to devices on the user’s local network. Why does it do that? Officially in order to connect to TVs/speakers, but what else could it decide to do with the access it’s granted?

There is a separate permission at least on iOS where an app that is connected over wifi has access to the local network.

Of course an app that streams video over the internet can “access wifi”

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

#146
post #143

Earlier quoted context omitted.

Which actually makes me more sympathetic to Chrome not (yet) adopting JPEG-XL. Don't get me wrong, I think JPEG-XL is a great idea, but to everyone saying "how can supporting another image format possibly do any harm", this is the answer.

Why not implement all image codecs in a safer language instead? That would seem to tackle the problem at its root rather than relying on an implementation's age as a proxy for safety, given that that clearly isn't a good measure.

That's a great question, and I'd love to know the answer.

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

#147
post #23

Here we go again... NSO Group has a long history of 0-click, 0-days against iMessage, and just a few months ago Kaspersky caught a different zero day iMessage exploit targeting their staff. If Apple repeatedly fails at securing their devices from an attack vector that has been demonstrated over, and over, and over... no wonder China is banning government officials from using their devices.

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

It's hard to give examples because "advanced 0-days" may mean everything

but somehow our society still moved everything to digital world and hasn't collapsed yet

meanwhile there are definitely shitton of highly motivated people trying to break systems

so, it is somehow possible to writer *safer* systems

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

#148
post #143

Earlier quoted context omitted.

Why not implement all image codecs in a safer language instead? That would seem to tackle the problem at its root rather than relying on an implementation's age as a proxy for safety, given that that clearly isn't a good measure.

That's a great question, and I'd love to know the answer.

Often it's infeasible to justify rewriting a lot of existing code, but my point is that these days this concern shouldn't really be an obstacle to integrating a new codec.

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

#150
post #123
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...

Again buffer overflow in image decoding. Would think apple might just #threatmodel and #fuzz that to death... but you would be wrong. 2.7T market cap company can't do this...

Apple has a long history of investing in all kinds of mitigations and security devices that make the App Store model secure and an equally long history of procrastinating on what is again and again and again causing their customers to be exploited.
Post reply on HN