And NSO is the value option. Now imagine what nation states with an actual budget have at their disposal.
How can you be so sure NSO is not funded by nation state(s)? :)
A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
151–160 of 360 posts
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#152Earlier quoted context omitted.
Signal lets you embed animated images but they still won't let you send native resolution images from your phone to someone else. Signal drastically recompresses any image sent. The only end to end encrypted software I know of that allows that is iMessage.
How could Signal recompress images while retaining end-to-end encryption? Wouldn't any "recompression" happen entirely on the client-side, and therefore be fair game for hackers to bypass with their own payloads?
https://sneak.berlin/20210425/signal-is-wrecking-your-images...
It's done clientside, and you can't remove it (on iOS) because only official Signal-published builds will receive push notifications of new messages from Signal servers (via APNS).
This doesn't apply to a sender of an exploit, but does apply to normal people who wish to send full res images or patch out the DRM in the Signal app.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#153Earlier quoted context omitted.
A large percentage of the planet has personal sensitive data stored by Google. If that data leaks, even due to a bug in another company's product through which Google has no fault, Google suffers. Google greatly benefits by having a secure Internet.
On this note, has google ever had a breach? I actually can't think of one off the top of my head, which is impressive for a company like google with so much data and such a large footprint Either their security or PR is great (or both?)
> has google ever had a breach?
They've been completely breached by Chinese agencies in the past, and IIRC the revelations in the Snowden leaks prompted them to redo their entire internal networking layout because of concerns about state-level spying.
On the Android front they keep tightening up access (removing more power from root, more use of SELinux and other controls) because of breaches in one form or another.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#154Looking forward to seeing the PDF that implements FizzBuzz in the NSO JBIG2 instruction set.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#155Since NSO is able to do these 0 click exploits on iphones does this mean they have have hacked apple engs as well and have copies of iOS lying around?
That was my first guess reading this. Like they just HAVE to have the source code right?
Nah that’s what tools like IDAPro and Ghidra are for. You don’t need source although it does help.
That said, the particular component this targets is open source. It’s the JBIG2 decoder that is part of XPDF.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#156Earlier quoted context omitted.
Project Zero is a team of security analysts employed by Google tasked with finding zero-day vulnerabilities. https://en.wikipedia.org/wiki/Project_Zero?wprov=sfti1 Don’t think of these folks as “google” employees. Think of them as “really good hackers with corporate sponsorship”. They look for flaws in everything - windows, apple, Linux, and google software. You should read some earlier blog posts, they’re really hig…
how does Google benefit from this?
The NSO are as much Google's enemy as Apple's.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#157NSO get way too much credit/dramatization these days. They are mostly 2 things * a shiny UI for customers * a bank of 0-days Those 0-days could be found in house, could be brought in from a new employee copying a previous employer, or could simply be purchased. Most people in the IDF understand when a great security researcher leaves 8200, the company they move to will probably have some of their secrets, theres real…
I think you get credit for having a bank of actual zero days, self-discovered or not
Trying to trivialize the threat they pose only helps NSO
Plus, "willing to sell to nations with bad human rights records" should be on that list
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#158Earlier quoted context omitted.
Dear sir, the entire NSA staff are currently plugging away on that pesky P=NP problem, including datacenter janitors.
I have suspected for awhile now that the bitcoin blockchain is actually an attempt to break SHA-256. Bitcoin is built around incentives, and it has created an incentive for people all over the world to basically brute force this algorithm and maintain a recursive set of low entropy outputs. Which would make the btc blockchain an incredibly expensive and valuable data set, for someone armed with the right mathematical…
How could you break it without destroying its value?
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#159Earlier quoted context omitted.
> 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…
ROP chains are similar in spirit but typically created by hand and thus not all that long (several dozen steps, at most). Creating a 70,000 step program via a Turing tarpit is very interesting.
> 70,000 step program
My initial assumption was that they would compile a program, take the binary output as an image and JBIG2-compress it, as I don't really get how they would use the result of the binary operations to branch to different code. Reading the article a bit more, I think they can loop multiple times over the area, by changing w, h and line dynamically over each pass, which would give them some kind of basic computer. That part is still unclear to me, but that would indeed be a lot more impressive.
There are no details on how control flow is handed over to the program either, so it's possible that they loop multiple time over the scratchpad (1 loop = 1 clock cycle roughly), especially if the memory area is non-executable, and they have one shot at computing a jump pointer.
In any case, they can probably copy arbitrary memory addresses into the new "scratchpad" area to defeat ASLR (we'll see in part 2).
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#160This 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.