Live data from Hacker News

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

citizenlab.ca

151–160 of 886 posts

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

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

>no wonder China is banning government officials from using their devices. Do you actually think security is the reason they are being banned? I think the reasons are far more political than technical.

Same reason USA have forced Huawei to be banned around the place.

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

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

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

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

#153
post #140

These dudes are insane. I wonder how much exploits like this are worth…

Probably seven figures

8 figures. easily.

Apple itself pays $1-million for bug bounties of this type.

https://security.apple.com/bounty/categories/

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

#154
post #17
post #12

I wonder if the lockdown mode would have prevented this attack? Has an iPhone in the lockdown mode been hacked so far, using a zero day vulnerability (not tricking the user to install a malicious program)?

It does. The page even recommends lockdown mode as a mitigation for affected parties (people who aren't updated)

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

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

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

There are efforts to do that, notably https://github.com/google/wuffs

RLBox is another interesting option that lets you sandbox C/C++ code.

I think the main reason is that security is one of those things that people don't care about until it is too late to change. They get to the point of having a fast PDF library in C++ that has all the features. Then they realise that they should have written it in a safer language but by that point it means a complete rewrite.

The same reason not enough people use Bazel. By the time most people realise they need it, you've already implemented a huge build system using Make or whatever.

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

#156
post #99

Earlier quoted context omitted.

Android is moving away from C and towards more secure languages. From one of their recent blog posts, the majority of code written for android is now in memory safe languages.

Is the programming language likely the issue here?

Of course, it's not necessary to use a language where "Give control of your phone to remote attackers" is one of the possibilities at all.

General purpose languages, whether that's something like C or Rust or even Javascript are not the appropriate tool. Turing Completeness is a bad idea from a security point of view, not a wonderful feature.

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

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

I understand that, and I'm partially assessing that in the context of any high targets who might be using the latest Android flagship, that frankly still suffers from the same problem as all Android phones.

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

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

Software written in Ada/SPARK.

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

#160
post #148

Earlier quoted context omitted.

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.

It should certainly lower the bar of adopting a new codec if the implementation is in a memory-safe language.

Even so, it is more code, and somewhat more risk. Lack of safety elsewhere might end up using code that is otherwise safe in order to build an exploit (by sending it something invalid that breaks an invariant, or building gadgets out of it, etc.).

Post reply on HN