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

301–310 of 886 posts

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

#301

Post by saagarjha »

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/

This decoder is actually maintained by Google.

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

#302

Post by 0xcde4c3db »

Horffupolde wrote: post #265

[flagged]

Yes. There's at least a principled discussion to be had about the pros and cons of something like "full disclosure" vs. "responsible disclosure", but based on everything that's come out about the company I'm pretty comfortable at least provisionally tossing NSO Group in the same bucket as the ghouls who charge prisoners a per-minute fee for phone calls to their families.

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

#303

Post by hollerith »

jacquesm wrote: post #216
14 wrote: post #122

Earlier quoted context omitted.

What is frustrating is the NSO group continues to exist despite all the bad they do. How many people are they responsible for being on the receiving end of a bone saw?

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.

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

#304

Post by saagarjha »

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?

They are.

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

#305

Post by RhodesianHunter »

jacquesm wrote: post #273
phendrenad2 wrote: post #226

Earlier quoted context omitted.

Software liability would effectively crush smaller companies, unable to keep up with the lawsuits, because they don't have billions in the bank.

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

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

#307

Post by saagarjha »

nielsbot wrote: post #100
Gigachad wrote: post #86

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.

Apple also has memory-safer languages it is moving to: Swift: A memory-safer systems programming language: https://www.swift.org Firebloom: A memory-safer C variant: https://support.apple.com/en-il/guide/security/sec30d8d9ec1/... Not sure what the answer is for existing memory-unsafe code.

https://www.youtube.com/watch?v=lgivCGdmFrw

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

#308

Post by saagarjha »

tialaramex wrote: post #120
Gigachad wrote: post #86

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.

And for this problem specifically Android can use WUFFS. WUFFS is a special purpose language for Wrangling Untrusted File Formats Safetly. Trading away generality (the ability to write a program which say, sends email) gets them complete safety and excellent performance. In Rust we can't trivially write a bounds miss by mistake . But in WUFFS we just can't write a bounds miss at all. Like, that's not a thing in WUFFS…

Would any of your comment change if I told you the bug was in a Google image parser that they currently also ship to production?

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

#309

Post by Zetice »

agnosticmantis wrote: post #297

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?

Because “hunting down and extinguishing” is a wild overreaction?

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

#310

Post by saagarjha »

ajross wrote: post #250
ok123456 wrote: post #133

Earlier quoted context omitted.

On Android you can disable automatic link preview and downloading of MMS messages. You can also swap out the application that handles text messages entirely. This eliminates this whole class of attack.

Also the application that handles text message is itself sandboxed and limited to a fixed set of permissions (to be fair, that include messaging other humans, so an exploit would still be very bad, just not "remote root" bad). That's the part that is still unclear with this BLASTPASS business. Surely iOS isn't running the messaging app as a device root, right? There's some other presumably-unpatched privilege elevati…

Yes. The ImageIO vulnerability just allows for an initial foothold.
Post reply on HN