A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution • Hacker News Board

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#321

Post by pjmlp » Thu, Dec 16, 2021, 3:31 PM UTC

olliej wrote: post #225

codedokode wrote: post #204

I think that allowing overflows to go unnoticed is a mistake. Overflow on addition should cause an exception by default. It should be easy to implement in hardware and as it is UB in C, correctly written programs wouldn't break. For example, imagine if you are counting money and because of the overlow millions turn into several cents. Another evil thing is indirect jumps. They should be implemented using an index int…

integer overflow is UB because on some architectures it was trapping. In practice for the last 30+ years the default behaviour has been non-trapping. So much so that making it trapping would break vast amounts of software that depend on it, so you can't change the general case behaviour in C, C++, etc, or "safe" languages like Java, C#, etc. Newer languages do recognize this and make trapping the default behaviour, b…

In C# you can have trapping behaviour by using checked, and in fact there is an ongoing discussion to enable it by default on VS project templates.

Same applies to the Algol linage.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#322

Post by pjmlp » Thu, Dec 16, 2021, 3:33 PM UTC

pornel wrote: post #197

dreamcompiler wrote: post #160

This is quite clever, but fundamentally it's only possible because of a buffer overflow. If the JBIG decoder had been written in Rust (just to cite one example of a language safer than C), this would have been impossible. Use dumb languages, pwn valuable prizes.

This case is easy. No need to rewrite: deleted code is even safer than Rust. Apart from Rust, Wuffs is also a good candidate for codecs: https://github.com/google/wuffs/blob/main/doc/wuffs-the-lang... Too bad that Swift isn't that good for low-level codecs, so a Swift rewrite of Messages couldn't remove C dependencies.

The sandbox mentioned on the article as the mitigation done by Apple, makes use of Swift.

https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#323

Post by pjmlp » Thu, Dec 16, 2021, 3:36 PM UTC

optymizer wrote: post #320

dreamcompiler wrote: post #160

This is quite clever, but fundamentally it's only possible because of a buffer overflow. If the JBIG decoder had been written in Rust (just to cite one example of a language safer than C), this would have been impossible. Use dumb languages, pwn valuable prizes.

As much as I'd like to agree with you, the real reason this is happening is because humans wrote the code and humans make mistakes. And even if you rewrite all of the software in Rust, it'll still have exploitable bugs. Does it matter if it's a buffer overflow or a rusty pan, if the end result is someone reading your device's memory?

In a language with proper bounds checking, regardless of which one, the result of this attempt would have been a core dump.

Sure there are other ways to then take advantage from killing a critical process, but it would be one attack vector less.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#324

Post by pjmlp » Thu, Dec 16, 2021, 3:38 PM UTC

kccqzy wrote: post #289

dreamcompiler wrote: post #160

This is quite clever, but fundamentally it's only possible because of a buffer overflow. If the JBIG decoder had been written in Rust (just to cite one example of a language safer than C), this would have been impossible. Use dumb languages, pwn valuable prizes.

Why are you so certain? The core of the exploit is an integer overflow issue: an attacker causes a 32-bit integer to overflow by repeated addition. Rust in release mode does not check for overflow on addition. Only debug mode Rust does that.

That was step one, it would then core dump on step two when trying to go over bounds.

Naturally this could eventually be used in another way.

There are no invicible fortesses, but some have enough defenses in place to keep almost everyone away or die trying, except the very resourceful ones.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#325

Post by drorco » Thu, Dec 16, 2021, 3:43 PM UTC

octoberfranklin wrote: post #311

drorco wrote: post #142

Earlier quoted context omitted.

I think you could also say the same about gambling, porn and other questionable industries. The thing is, it's usually much easier making money off these things then making money from solving impactful problems. If you're a regular joe and you could spend your next 5 years with a 100% chance of making millions for finding exploits, or a 0.01% chance of solving P=NP, I think the irrational decision would be picking th…

The problem isn't that they spend 5 years making fuck-you money. The problem is that they don't realize that they can stop once they have it.

I don't know what's the quantitative trend.

I do know of several founders whose first company was a nasty ad-tech company (spyware), and after making their millions, their second company is a much more honorable digital health company.

You probably can find examples where such people can keep on creating nasty companies, so it would be interesting to see if there was a research about whether or not people pursue more honorable goals after they get lots of cash.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#326

Post by shudza » Thu, Dec 16, 2021, 3:58 PM UTC

pradn wrote: post #66

rwaksmunski wrote: post #32

And NSO is the value option. Now imagine what nation states with an actual budget have at their disposal.

It's still pretty expensive! NSO charged a flat $500,000 fee for installing Pegasus. It charged government agencies $650,000 to spy on 10 iPhones; $650,000 for 10 Android users; $500,000 for five BlackBerry users; or $300,000 for five Symbian users.

A lot of people talking about governments as NSO's top clients... How do the governments actually pay them? Out of their pockets? State budget? In any ridiculous case, shouldn't this kind of payment be easy to track? Why is no one talking about this? Why isn't this forbidden on international level? The US (as world peacemaker) seem pretty chill about it. I thought this was 'merica!

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#327

Post by dylan604 » Thu, Dec 16, 2021, 4:16 PM UTC

user-the-name wrote: post #313

dylan604 wrote: post #249

Earlier quoted context omitted.

I'm thinking you're missing the larger idea. The whole point is that while these "geniuses" did something really "impressive" and difficult, there are just as really not-impressive and not-difficult things found in the wild that have caused problems as well.

Why bring that up? It is something everybody knows and it adds nothing to this conversation.

It's called counterpoint. It was actually found interesting by several people, but you can have your opinion that you don't find it intersting. It actually did add to the conversation as there were multiply replies to it. Your comment about it is the thing that doesnt really add to anything.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#328

Post by mrtesthah » Thu, Dec 16, 2021, 4:26 PM UTC

vmception wrote: post #59

ivraatiems wrote: post #20

It's a real shame that the people who came up with this exploit are working for NSO and not on solving P = NP or something. I'm sure if we got them and the ones working on crypto at NSA in a room together, we'd have it and clean unlimited energy in a week. I often feel sad thinking about how many brilliant engineers are dedicating their time to helping governments spy on people or other governments.

It just is another example that bug bounties are undervalued and the experience doing anything “white hat” is too disastrous to be worth it. Responsible disclosure is for the gullible. The market keeps saying “this is what its worth”

What if vulnerabilities’ PR cost to companies will always be less than the price on the black market for exploits?

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#329

Post by herodotus » Thu, Dec 16, 2021, 4:30 PM UTC

> Most of the CoreGraphics PDF decoder appears to be Apple proprietary code, but the JBIG2 implementation is from Xpdf, the source code for which is freely available.

When I worked at Apple, we encountered a Jailbreak exploit that relied on some poor code in one of the open-source type fonts. It appeared that someone committed a mod to the project that neglected to do an array bounds check, waited ONE YEAR!!! and then exploited the vulnerability to create a PDF document that would jailbreak a phone if the PDF was viewed.

I guess it is possible that something similar was done here.

Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution

#330

Post by jeffbee » Thu, Dec 16, 2021, 5:00 PM UTC

follower wrote: post #317

jeffbee wrote: post #295

Earlier quoted context omitted.

The "major email" people are pretty much the only people funding practical technology of the kind you just whined about. https://github.com/google/wuffs

Note the disclaimer on that page: > This is not an official Google product, it is just code that happens to be owned by Google. Which generally means that the original author worked at Google when they wrote this code & "chose" to let Google own the copyright of this project rather than fill out more paperwork. It doesn't imply the project was funded by Google--just that the author was a Google employee at some point…

That disclaimer appears at the bottom of every project that Google doesn't feel like officially supporting. Even the tcmalloc project has that disclaimer at the bottom and it's used in every single process running in Google datacenters right now. I think you'd be hard pressed to really make the case that WUFFS is not funded by Google.