Live data from Hacker News

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

googleprojectzero.blogspot.com

311–320 of 360 posts

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

#311
post #142

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.

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.

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

#312

Earlier quoted context omitted.

Stop weird machines! http://langsec.org/occupy/

In this particular case: If you are Wrangling Untrusted File Formats, you should be doing so Safely, using WUFFS. You can't make this mistake in WUFFS. Your WUFFS image decoder might decode the image incorrectly, maybe Rudolph has a green or blue nose, maybe he's upside down or just a sea of noise, but it can't have a buffer overflow even if you screwed up really badly. For example, any equivalent of the repeated add…

the problem is, this is an ancient PDF feature from the 90s that nobody has time to write and debug

so they just took an open source parser and slapped it in there

it’s hard to rewrite PDF parsing to a new language so that everything still works. Especially those weird features that people forgot about.

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

#313

Earlier quoted context omitted.

To be clear, what this exploits is nothing like what you've mentioned. The article does a very good job of describing the relevant parts of the image format. They built a VM inside of an images single pass decompression route. I'd highly recommend reading the article. This is just one of the exploits in a very large chain. To quote some of the nations top security researchers: > Based on our research and findings, we…

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.

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

#314

Earlier quoted context omitted.

I remember reading this. Are you aware of a detailed account? Regardless of Indian politics, has it actually been proven/researched?

> has it actually been proven/researched? Yes. "The Wire has confirmed the numbers of at least 40 journalists who were either targets or potential targets for surveillance. Forensic analysis was conducted on the phones of seven journalists, of which five showed traces of a successful infection by Pegasus." https://thewire.in/rights/project-pegasus-list-of-names-unco... The forensic analysis was conducted by Amnesty I…

Thank you. I had previously re as the citizenlab report, but didn’t realise that Indians were targeted as well.

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

#315
post #172

Earlier quoted context omitted.

I think what he means with historically is before ASLR, DEP, and other mitigations, where a buffer overflow meant you can simply overwrite the return pointer at ESP, jump to the stack and run any shellcode. Mitigations have made exploitation much, much more complex nowadays. See for example https://github.com/stong/how-to-exploit-a-double-free

Exactly. This escape is technically quite cool frankly in terms of some creativity. That said, my own view is that messages from untrusted contacts should be straight ascii, parsed in a memory safe language with no further features until you interact (ie, write back etc).

Safeguards should be applied uniformly to all senders. A trusted sender could have been already exploited.

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

#316
Yeah, maybe next time don't "cancel" wikileaks just because they leaked something from your political side(referencing the DNC & Democratic leaks here).

The vault7 was mind-blowing and somehow reinforced what was de facto knew but until then no solid proof was there[merely that quite everything is compromised directly, and when that's not the case, your output is mined],available to the large public.Again, if the Media was more keen on that issue (Privacy, 3-letter agencies being abusive,etc) then people would remember the issues that exist in most computing systems today.

For people who at least skimmed through those vulnerabilities,tools, and leaked documents, it's not surprising at all that these kind of exploits are still out there.It's actually disappointing and frankly pathetic that people don't pay attention to some things because they disagree with the source of information(By the way WL revealed things from the entire spectrum: right/left, Russia/western countries/Asia/etc).These 'NSO leaks' are not eye-opening exploits/techniques, but don't let me spark the bubble of "modern infosec journalism".

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

#317
post #292

"And just because the source filename has to end in .gif, that doesn't mean it's really a GIF file. The ImageIO library, as detailed in a previous Project Zero blogpost, is used to guess the correct format of the source file and parse it, completely ignoring the file extension. Using this "fake gif" trick, over 20 image codecs are suddenly part of the iMessage zero-click attack surface, including some very obscure an…

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.

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

#318
I'm surprised that iMessage doesn't restrict content to a subset of predefined, preapproved, battle hardened types and variants. Any other content has to be converted before transport. Otherwise that content is just treated as payload (attachment).

Why use a library to support every format ever made? To inline image previews? Just show a thumbnail.

Why do anything with PDF? Just show a thumbnail.

I'm pretty sure iMessage already down samples the puppy pictures I send to my mom, and doing some kind of conversion to tunnel across MMS for non iMessage recipients (eg Android phones).

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

#319
post #292

"And just because the source filename has to end in .gif, that doesn't mean it's really a GIF file. The ImageIO library, as detailed in a previous Project Zero blogpost, is used to guess the correct format of the source file and parse it, completely ignoring the file extension. Using this "fake gif" trick, over 20 image codecs are suddenly part of the iMessage zero-click attack surface, including some very obscure an…

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

[deleted]

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

#320

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?

Post reply on HN