Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

citizenlab.ca

Post reply on HN
Print view View original

361–370 of 886 posts

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

#361

Post by sneak »

Obscurity4340 wrote: post #336
andrewia wrote: post #271

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 would argue that iMessage is way to problematic to be used safetly, at all. By anyone. Full-stop. It also seems to be the primary attack vector of NSO related zero-days as well and its become known that phone country/area codes have relevance to its chance of succes in past exploits, which suggests a phone/messaging type attack vector.

It's also insecure. The sync keys for iMessage are backed up in the non-e2ee iCloud Backup, which means that iCloud serves as a key escrow for iMessage's e2ee, rendering it useless (as Apple, which is definitively not an endpoint, has a private key of the participant and can read all the messages in real-time).

iMessage should be assiduously avoided.

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

#362

Post by sneak »

jiofj wrote: post #313
barryrandall wrote: post #279

Earlier quoted context omitted.

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.

You can leave lockdown off, and disable iMessage.

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

#363

Post by jacquesm »

RhodesianHunter wrote: post #305
jacquesm wrote: post #273

Earlier quoted context omitted.

If your software can cause billions of damage and you don't have billions in the bank you are in the wrong business, or acting very irresponsibly.

Small companies can't cause billions in damage though...

The argument wasn't mine.

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

#364

Post by jacquesm »

bawolff wrote: post #275
jacquesm wrote: post #257

Earlier quoted context omitted.

I don't understand your comment either. You say you don't understand and then you give a choice between two narrow interpretations neither of which seems to cover what I wrote. To make this a bit more productive: If Apple were liable for their defective products then they might decide not to ship them at all until they can be sure enough that the risk of the lawsuits putting them out of business is small enough that…

> If Apple were liable for their defective products then they might decide not to ship them at all until they can be sure enough that the risk of the lawsuits putting them out of business is small enough that they can absorb it. > This worked wonders for other industries (notably: automotive, airlines, medicine). It may slow them down a bit, you may have a wait a bit longer for the next iteration of some gadget. But…

If there is anything that is life critical for a large number of people then it is their phones.

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

#365

Post by acdha »

lazide wrote: post #357
acdha wrote: post #348

Earlier quoted context omitted.

I understood but am skeptical of that - they'd block sale of the entire company but I think it'd be a surprise if they prevented a bunch of Israeli nationals from accepting prestigious jobs with an American company.

1) of course they would. Or worse (see Gerald bull). 2) any company doing that would have to be insanely naive or reckless.

1. Consider that there might possibly be room between designing long-range weapons for an enemy state and working for an allied country.

2. Indeed: that’s my second paragraph above.

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

#366

Post by jacquesm »

acdha wrote: post #277
jacquesm wrote: post #257

Earlier quoted context omitted.

I don't understand your comment either. You say you don't understand and then you give a choice between two narrow interpretations neither of which seems to cover what I wrote. To make this a bit more productive: If Apple were liable for their defective products then they might decide not to ship them at all until they can be sure enough that the risk of the lawsuits putting them out of business is small enough that…

> If Apple were liable for their defective products then they might decide not to ship them at all until they can be sure enough that the risk of the lawsuits putting them out of business is small enough that they can absorb it. I think this works best at that level, like if there’s a sliding scale based on your company’s importance to normal people’s security. I think a lot of developers are worried that their two p…

Exactly. And if Apple can't do it then we should declare defeat.

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

#367

Post by internetter »

comment0r wrote: post #332
rank0 wrote: post #140

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

According to Zerodium [1] it would be up to 2 million USD in this case. [1] http://zerodium.com/program.html

Interesting that android FCPs are worth more than iOS counterparts. Does that mean android is more secure?

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

#368

Post by Obscurity4340 »

sneak wrote: post #361
Obscurity4340 wrote: post #336

Earlier quoted context omitted.

I would argue that iMessage is way to problematic to be used safetly, at all. By anyone. Full-stop. It also seems to be the primary attack vector of NSO related zero-days as well and its become known that phone country/area codes have relevance to its chance of succes in past exploits, which suggests a phone/messaging type attack vector.

It's also insecure. The sync keys for iMessage are backed up in the non-e2ee iCloud Backup, which means that iCloud serves as a key escrow for iMessage's e2ee, rendering it useless (as Apple, which is definitively not an endpoint, has a private key of the participant and can read all the messages in real-time). iMessage should be assiduously avoided.

Was going to mention. iMessage seems to be that golden key thing the FBeye asked them for back in 2015 in San Bernadino (insofar as iCloud itself isn't a/the key itself, already)

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

#369

Post by jxcl »

sneak wrote: post #361
Obscurity4340 wrote: post #336

Earlier quoted context omitted.

I would argue that iMessage is way to problematic to be used safetly, at all. By anyone. Full-stop. It also seems to be the primary attack vector of NSO related zero-days as well and its become known that phone country/area codes have relevance to its chance of succes in past exploits, which suggests a phone/messaging type attack vector.

It's also insecure. The sync keys for iMessage are backed up in the non-e2ee iCloud Backup, which means that iCloud serves as a key escrow for iMessage's e2ee, rendering it useless (as Apple, which is definitively not an endpoint, has a private key of the participant and can read all the messages in real-time). iMessage should be assiduously avoided.

This is less true now, with the option to enable “advanced data protection”. Turning this setting on disables Apple’s access to your iMessage keys along with a bunch of other stuff, though of course if you get locked out, Apple can’t help you

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

#370

Post by Dylan16807 »

saagarjha wrote: post #318
Dylan16807 wrote: post #242

Earlier quoted context omitted.

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 cours…

Mapping pure RGBA across processes is safe, but also a single extra copy is not a big performance impact in the first place for an image decoder.

Configuring the IOMMU is one of the easiest parts of doing it in hardware. That's not going to make things "difficult to secure". And allocating the chunk of memory is trivial.

Post reply on HN