I know that I'm generalizing and also being somewhat sarcastic, but can't we blame the majority of exploits on the von Neumann architecture?
We can blame the majority of software on the von Neumann architecture
A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
221–230 of 360 posts
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#222Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#223Since 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?
I mean, it would just be a prudent business move once the first PoC comes out right? You know that Apple is going to patch it eventually. It totally makes sense to try to pop a dev box and exfiltrate the source code. The only question is if they can make it past Apple's network security - it's unlikely that devs are allowed to take their work MacBooks with iOS source code home.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#224It'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.
People of this caliber are avaliable here: https://ctftime.org/ Here you have a list of decade of performance of experts/top competitors in: security, reverse engineering, crypto, low lvl, malware analysis, OS internals, memory corruption some of them even work at Google Project Zero :)
And some of them work at NSO...
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#225I 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, but "rewrite everything at once" is simply not a tractable problem.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#226Amazing apple let this slip past. Seems pretty obvious why this is bad design, easy to exploit, etc. so maybe it was intentional and already being used by us when the NSO group caught wind through “back channels” and hopped on the gravy train.
"iMessage's .gif handling was a bit sloppy" is a believable problem; the idea that it was done deliberately to facilitate access to what amounts to a VM running in an old image compression format is a big stretch. This isn't like goto fail, and even that one could be explained by developer oversight.
I always felt that goto fail seemed very much like an incorrect merge resolution
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#227Since 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?
Source code doesn't help that much, and sometimes the assembly makes some bugs more obvious. They really don't need the source. They just decompile it.
People without reverse engineering experience often think there's a massive difference between white-box and black-box auditing, but there really isn't. Yes, it takes longer, but not ridiculously so.
NSO aren't interested in being an overtly criminal operation; breaking into Apple and stealing source would be a giant liability they don't need to have. Their game is feigning ignorance as to what their customers do with their software. They can't afford to be caught commiting crimes directly.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#228Amazing apple let this slip past. Seems pretty obvious why this is bad design, easy to exploit, etc. so maybe it was intentional and already being used by us when the NSO group caught wind through “back channels” and hopped on the gravy train.
I mean the actual exploit is in decades old xpdf code, so that seems unlikely? The gif thing is simply the way that they get to the xpdf JBIG2 decoder.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#229It'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.
all the other best minds of our generation are working on getting people to click more ads
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#230Earlier quoted context omitted.
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
maybe "amoral"