> My other compression format is turing-complete!
A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
281–290 of 360 posts
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#282As 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…
> 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 impressiv Might as well praise German logistics circa 1940-1945.
[deleted]
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#283It'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.
What if they are working on both?
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#284One the one hand you've got people writing insanely complex hacks like this. On the other hand there's the guy who was doing whatever he wanted for years just by crafting dodgy plist files. https://blog.siguza.net/psychicpaper/
Same class of bug that completely broke Android app signing. In that case it was about ZIP file parsing differences (apps checked at install time by one parser, executed using another parser). And also the same bug class that allowed us to bypass Nintendo's mitigation for the Twilight Hack (Wii Zelda savegame exploit), twice. In that case it was about how they handled the savefile archives slightly differently from existing save data and the game itself.
Having multiple parsers for security-sensitive data that isn't just outright signed at an external layer is always a recipe for disaster.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#285Could it be that authors of this post are trying to portray NSO as more powerful than they actually are? Could there be elements in googleprojectzero that work for NSO?
It is a well known method to make a spy operation more elaborate to worry adversaries.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#286Just to understand, what is the blast radius of this exploit?
Do they just have access to the whole process memory of the iMessage process?
Or does it go beyond that?
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#287Earlier quoted context omitted.
No, you can't. Because too much code is completely broken if you do. The only things that make use of overflow being UB are optimizing compilers, and they have reliably broken code for because of this for 20 years. This means most developers have realized that pretending non-twos-complement architectures still exist is nonsense, and both C and C++ have significant pressure to actually define overflow as being 2c.
> Because too much code is completely broken if you do. Any code that gets broken by that already has a security bug. > The only things that make use of overflow being UB are optimizing compilers, and they have reliably broken code for because of this for 20 years. Exactly! Code that can be broken by this is already broken. Using -fwrapv won't make it any more broken, it just makes the way it breaks safer.
No. It isn't broken. There is a huge amount of code that assumes this behavior, and works correctly, because that is the way hardware works. That is a huge amount of code that has worked reliably for decades, because it is correct, because the expected behavior matches the hardware behavior.
Saying "it is UB therefore is a security bug" is nonsense.
Saying it shouldn't be UB is useful, and is being addressed by the C and C++ standardization committees, and that work will not change the behavior, it will simply remove the "it's UB" nonsense that optimizers occasionally use. At that point the defined behavior will be a twos complement overflow.
Saying it's UB and therefore can be arbitrarily broken is equally nonsense, breaking code that is correct, within the confines of actual real machines, for no reason other than "it's UB" is not anymore helpful than saying "why don't you just rewrite it all in X".
It's actually incredibly difficult given your definition of what is allowed, to write anything in C that is not UB.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#288Earlier quoted context omitted.
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 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 You can change it in C and C++, since the current behaviour is undefined i.e. give control of your computer to hackers. GCC and Clang should make -ftrapv the default. They won't, becaus…
Out of band update:
The overflow that starts this exploit chain is an unsigned overflow. Unsigned overflow in C and C++ has defined behavior. That behavior is wrapping.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#289This 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.
Re: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
#290Earlier quoted context omitted.
> Because too much code is completely broken if you do. Any code that gets broken by that already has a security bug. > The only things that make use of overflow being UB are optimizing compilers, and they have reliably broken code for because of this for 20 years. Exactly! Code that can be broken by this is already broken. Using -fwrapv won't make it any more broken, it just makes the way it breaks safer.
No. It isn't broken. There is a huge amount of code that assumes this behavior, and works correctly, because that is the way hardware works. That is a huge amount of code that has worked reliably for decades, because it is correct, because the expected behavior matches the hardware behavior. Saying "it is UB therefore is a security bug" is nonsense. Saying it shouldn't be UB is useful, and is being addressed by the C…
> There is a huge amount of code that assumes this behavior, and works correctly, because that is the way hardware works.
It doesn't though, because gcc et al don't care how the hardware work, they can and do happily miscompile that kind of code into security vulnerabilities instead. If you're talking about embedded code that's compiled with a specific vendor's non-optimizing compiler then yes (but changing GCC and Clang's defaults will have no effect on that kind of code), but if you're talking about code for mainstream desktop/server systems then no, it already doesn't and can't rely on wrapping overflow.
> Saying it's UB and therefore can be arbitrarily broken is equally nonsense, breaking code that is correct, within the confines of actual real machines, for no reason other than "it's UB" is not anymore helpful than saying "why don't you just rewrite it all in X".
But it's not correct, not just in theory but in practice. In real life, code that does this and gets compiled with a modern optimizing compiler like GCC or Clang is already an RCE unless proven otherwise. Yes wrapping is what a naive assembly translation would do. But the compilers don't do naive assembly translation and haven't for decades.
> It's actually incredibly difficult given your definition of what is allowed, to write anything in C that is not UB.
Yes, which is why we keep getting security vulnerabilities like this one.