Oh and the follow-up in the comments: (Regarding Sandboxie reconfiguration mitigating some of the attacks)
> I tested with SBIE4 and indeed it is quite different and has security improvements over what we tested in our report. Great job by the author!
> However, our kernel exploits still work flawlessly – no issues there. You need to remember that SBIE3/4 (and other similar app sandboxes) are kernel mode drivers and they will always have some fundamental limitations. Blocking access to specific DLL’s is far from a practical use case as you have no idea where the next patch is going to come (BTW similar capability has been available in HIPS technology for several years and very few people use it)
> Once time permits, we’ll probably update our analysis with the latest SBIE4. However, this is not our core focus, the idea of this research was to simply enumerate the fundamental limitations of application sandboxing tech.
Of course, folks might be first in line to point out that nothing's perfect, and user-error can get around a lot of security... Nobody would argue sandboxing is an excuse to not patch systems, except with antivirus you might increase your attack surface while trying to detect attacks with something that can't be easily circumvented. Trade-offs. Can you trust sandboxing to prevent damage from malware or do you need some kind of warning that something strange is going on?
