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
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