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

381–390 of 886 posts

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

#381

Post by jonhohle »

citrin_ru wrote: post #170
rakkhi wrote: post #123

Earlier quoted context omitted.

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

A while ago I was surprised to learn that MS Internet Explorer had team of about 10 developers (I expected more) when MS already had more than 50000 employees total. Now knowing a bit more how sausages are made I would not be surprised to learn that this particular image decoder was maintained in Apple by a couple developers. To some extent this can be seen in corporations too: https://xkcd.com/2347/

If that. This weekend I ran into a TIFF decoding issue (Canon scanner produces TIFFs with embedded JPEG compression with different parameters than the outer TIFF container). This is an issue with libtiff and affects any Mac or iOS app using CoreGraphics, anything using ImagMagick, etc. GIMP, Nikon NX Viewer, and others with their own TIFF implementations are unaffected.

I doubt anyone at Apple cares. If a CVE is filed for libtiff, they’ll rebase, but I doubt they are actively fuzzing it or even have regression tests for it.

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

#382

Post by j0hnyl »

aaomidi wrote: post #344
j0hnyl wrote: post #131

Earlier quoted context omitted.

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

Only when they’re unknown. Once they’re known they’re built into shit like kali Linux.

1-day / n-day zero click nso exploits are certainly not available in kali linux.

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

#384

Post by jonhohle »

astrange wrote: post #205
dragonwriter wrote: post #173

Earlier quoted context omitted.

Apple has annual revenue greater than the GDP of any of the bottom ~4/5 of nation-states.

The problem with internal bounties is that you'd be granting them to the people with power to put in the security holes they find.

Apple uses a ton of open source libraries. They could give bounties for security issues found in public releases.

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

#385

Post by hackmiester »

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.

You don't have to use iCloud Backup.

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

#386

Post by [deleted] »

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.

[deleted]

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

#388

Post by fortran77 »

mschuster91 wrote: post #239
dogma1138 wrote: post #178

Earlier quoted context omitted.

Apples revenue isn’t much lower than Israel’s GDP and NSO isn’t really a nation state actor.

NSO is reported to consist of mostly Unit 8200 staff. No way they're not deeply connected with the Israeli government.

This is a lie. It’s a UK owned company, part of Novalpina Capital. A division of their QCyber Group based out of Luxemburg.

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

#389

Post by RadixDLT »

hollerith wrote: post #303
jacquesm wrote: post #216

Earlier quoted context omitted.

At the risk of being boring: software liability would go a long way towards getting companies to do this work themselves. Even though Apple is the largest company on the planet an entity that has a small fraction of the budget is apparently able to do a better job. I don't see why Apple couldn't make those people an offer they can't refuse. That takes them off the market and has them doing something productive.

If Apple buys NSO Group and shuts it down, other firms are incentivized to enter the market especially because of the prospect of a nice payday if Apple buys the new firm, too.

apple will not be buying anything, the hacking tools that nso are using are stolen from the trhee letter agency

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

#390

Post by Veserv »

tlrobinson wrote: post #201
ruuda wrote: 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...

Maybe a dumb question, but why are media decoders, which are notoriously high risk, not well sandboxed?

Because sandboxing on iOS is terrible. Not that any of the other commercial vendors are any better.

If they could provide good sandboxes do you think the highest security certifications advertised on their website [1][2] would only certify protection against attackers with “basic attack potential”, the lowest possible level. Three whole levels below “moderate attack potential”. I mean, seriously, they certify their security sucks on their website, is it any wonder their security sucks.

[1] https://support.apple.com/guide/certifications/ios-security-...

[2] https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/CE...

Post reply on HN