What is being described will get you on your way to the NSO hack as a service, because their hack was using a decompression algo to build a virtual cpu of sorts and run it, in a single pass of the decompression process.
How hard would it be to embed source code in such a way that you could also build a limited cpu to then run this embedded source code in memory with a single pass of graphic processing or decompression algo?
Yeah, but because of NSO I now look at every mandatory or common practice process that is used on a file to see if the NSO methods can be used for exploitation.
For example, PNG seems benign, but what it was stored in a zip file of sorts, could the MS windows zip process be exploited, could 7-Zip be exploited or even PKzip for that matter, do you see where I am coming from?
What about if I embedded some icons and image files as a resource in an application exe or dll. You have persistence then, even if its just a beacon or some unique domain name lookup to track the app online.
https://docs.microsoft.com/en-us/windows/win32/menurc/enumer...
Would it be possible to build something into a webpage or imagefile on a popular website where it can exploit the methods NSO have/are using?
Maybe we should go back to reading the internet using wget?
Yeah, but because of NSO I now look at every mandatory or common practice process that is used on a file to see if the NSO methods can be used for exploitation.
NSO is definitely neither the first nor the only one to do this, but let's move on.
For example, PNG seems benign, but what it was stored in a zip file of sorts, could the MS windows zip process be exploited, could 7-Zip be exploited or even PKzip for that matter, do you see where I am coming from?
Any nontrivial parser written in an unsafe language has a potential for being exploitable, that's for sure.
What about if I embedded some icons and image files as a resource in an application exe or dll. You have persistence then, even if its just a beacon or some unique domain name lookup to track the app online.
This is why we have code signing. Well, that works unless the ASN.1 parser or the signature verifier has got some security issues, of course.
Comments
Is this a troll post considering the NSO hacking post seen here https://news.ycombinator.com/item?id=29640474 and the google project zero post? https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
What is being described will get you on your way to the NSO hack as a service, because their hack was using a decompression algo to build a virtual cpu of sorts and run it, in a single pass of the decompression process.
How hard would it be to embed source code in such a way that you could also build a limited cpu to then run this embedded source code in memory with a single pass of graphic processing or decompression algo?
No, that's irrelevant here.
PNGSource embeds code in ancillary chunks. That's it. No code execution. No steganography (yet).
Yeah, but because of NSO I now look at every mandatory or common practice process that is used on a file to see if the NSO methods can be used for exploitation.
For example, PNG seems benign, but what it was stored in a zip file of sorts, could the MS windows zip process be exploited, could 7-Zip be exploited or even PKzip for that matter, do you see where I am coming from?
What about if I embedded some icons and image files as a resource in an application exe or dll. You have persistence then, even if its just a beacon or some unique domain name lookup to track the app online. https://docs.microsoft.com/en-us/windows/win32/menurc/enumer...
Likewise, what about compression built into HTML/Web browsers, could that be exploited? https://en.wikipedia.org/wiki/HTTP_compression
Would it be possible to build something into a webpage or imagefile on a popular website where it can exploit the methods NSO have/are using? Maybe we should go back to reading the internet using wget?
NSO is definitely neither the first nor the only one to do this, but let's move on.
Any nontrivial parser written in an unsafe language has a potential for being exploitable, that's for sure.
This is why we have code signing. Well, that works unless the ASN.1 parser or the signature verifier has got some security issues, of course.
It's usually much easier to just exploit the renderer/JavaScript engine.
This is basically how malware distribution works over the web, just look for some VirusTotal samples...
If we're at that level of paranoid, bugs in the HTTP parser, TLS implementation, or the TCP/IP stack should be just as sensitive.
How many zero days exist when you put a new distro online in order to update, and thats without looking at the firmware for bugs.
...why are you even talking to some stranger here then, is it worth enough to risk being exploited with a RCE 0day
Like, uh, just define a clear threat model, accept risks, and move on??? Or just don't use computers