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

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

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

131–140 of 360 posts

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

#131

Post by bscphil »

sterlind wrote: post #107
walrus01 wrote: post #90

Earlier quoted context omitted.

It's my understanding that the signal client which is sending the image reads the jpg/png/whatever image file from local storage, recompresses it local client side, and then sends the smaller version.

then that offers no security at all, since an attacker could use a hacked client. unless clients also refuse to receive anything but one, very well-validated, format, so that sending anything funky would be futile.

No, just have the server reject anything at the /SendMessage endpoint over a certain size; presumably the client is resizing / recompressing images to hit a specific target.

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

#132

Post by cycomanic »

eevilspock wrote: post #98
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.

“The best minds of my generation are thinking about how to make people click ads. That sucks.” ~ Jeff Hammerbacher, fmr. Manager of Facebook Data Team, founder of Cloudera This quote isn't just about people working directly on ad tech and ad targeting algorithms, but any product that is "free" and ad supported.

As a side note I just went to the Cloudera website, because I did not know about the company.

After selecting "Reject all" in the cookie dialog, the cookie was literally spinning (they have a spinning wheel animation for processing your cookie response!) for >5s on "We are processing your cookie settings request". If this is what the best minds of our generation are achieving then help us god!

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

#133

Post by walrus01 »

bscphil wrote: post #131
sterlind wrote: post #107

Earlier quoted context omitted.

then that offers no security at all, since an attacker could use a hacked client. unless clients also refuse to receive anything but one, very well-validated, format, so that sending anything funky would be futile.

No, just have the server reject anything at the /SendMessage endpoint over a certain size; presumably the client is resizing / recompressing images to hit a specific target.

there is no 'server' in a signal client-to-client link except as a directory server for the clients to find each other

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

#134

Post by 2OEH8eoCRo0 »

nlh wrote: post #53

As other have commented, this is absolutely mind-bogglingly hard core. Kudos to the NSO group engineers who designed and built this (regardless of your allegiances and whether you like or dislike that they do this and whether it's objectively good or evil or somewhere in between, you have to admit that it's deeply technically impressive). Does anyone have a sense of who they sold this to and who used this particular…

I admire its purity.

> Does anyone have a sense of who they sold this to and who used this particular 0-click exploit?

From the article:

> Earlier this year, Citizen Lab managed to capture an NSO iMessage-based zero-click exploit being used to target a Saudi activist.

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

#135

Post by fooyc »

ridaj wrote: post #94

... or why your next design review should probably ask "is this input format a Turing-complete language?" This shows how un-theoretical that question is.

"Is this a memory safe language" should be a critical question for any external facing application, too

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

#136

Post by earthscienceman »

sterlind wrote: post #104
ASalazarMX wrote: post #40

Earlier quoted context omitted.

If they solved P = NP, their first intention would be selling it to the highest bidder. NSO hackers are the digital equivalent of mercenary soldiers.

kinda like Werner von Braun, maybe. he just wanted to make rockets. whether they were for Nazi Germany or the US didn't matter, whether they were missiles or spacecraft didn't matter, he just wanted to build them.

Which we have a descriptive word for: unethical. The colorful word would be: disgusting

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

#137

Post by kingaillas »

nafey wrote: post #120
kingaillas wrote: post #65

Earlier quoted context omitted.

Well for one, the safety of encryption rests on certain problems being intractable. (In a theoretical sense; there are always implementation bugs that destroy security). If P=NP, then those previously thought to be intractable problems, are actually tractable. And the foundation of a lot of security-related engineering collapses.

Is proving P = NP equivalent to knowing how any intractable problem can be solved? Is it possible for P=NP and yet a class of intractable problems to remain unsolved?

It would mean that a large class of problems that have solutions that can be verified quickly can be solved quickly. Which cuts both ways.

While that means most protocols used for cryptography would need to be replaced (hashing, digital signatures, etc) it also means other combinatorics algorithms (traveling salesman, protein structure prediction) would become solvable which may been boon for logistics and/or computational science.

(I think this is correct) If P=NP there will still be intractable problems; they would be ones where the solutions can't be verified in polynomial time... along the lines of verifying the solution is correct is as complicated as brute forcing the solution.

Note: it's been a while since my computation theory class. ;) I am reading over https://en.wikipedia.org/wiki/P_versus_NP_problem and relearning the fine house of cards theoreticians have divided this problem into. There is a "consequences of P=NP" towards the bottom that sums it up better than I can.

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

#138

Post by AlexanderTheGr8 »

mark_mart wrote: post #110
iamricks wrote: post #92

Reading breakdowns like this gives me imposter syndrome

These people probably smartest developers in the world. I wouldn't compare myself with them.

You think? These devs are some of the devs in Israel. The best get too popular to work in secret labs like NSO. I find it hard to believe that the best devs are secret ones in Israel. But obviously, I could be wrong.

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

#139

Post by itp »

MayeulC wrote: post #128
onphonenow wrote: post #100

Earlier quoted context omitted.

Now - that is a big change. Historically the jump from overflow to RCE was much much shorter. Still the iMessage attack surface is just massive and running in an unsafe language kind of crazy?

> Historically the jump from overflow to RCE was much much shorter. Not really. I am about to read the article, but it sounds like return-oriented programming[1] chaining "gadgets" that are small bits of existing code that you can re-purpose into executing arbitrary code by manipulating the stack. Extremely common exploitation technique, even if not trivial. Who said an exploit or RCE was trivial to exploit? Edit: I…

Suffice it to say, this exploit was not simply chaining gadgets.

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

#140

Post by MarkSweep »

usmannk wrote: post #3

This is mind boggling. NSO used a compression format's instructions to create logic gates and then from there "a small computer architecture with features such as registers and a full 64-bit adder and comparator which they use to search memory and perform arithmetic operations", all within a single pass of decompression. Combine this with a buffer overflow and you've got your sploit.

Stop weird machines!

http://langsec.org/occupy/

Post reply on HN