Yep if you post your full (and properly configured) SBIE config and even comment it in every of its part it would be the most interesting. :-TU
But meanwhile let me focus on some aspect you seemingly neglected:
Well LUA (which in itself provide far more guarantees than SRP IMHO) is available in every Windows edition but Applocker is available only on Windows 7 Ultimate or Enterpise whereas SRP is not available on Home editions.
Indeed SRP can be bypassed quite easily even though it was created to provide admins with a way to control what executables could run locally: There is no doubt existing bypasses proves SRP enforcement might be compromised by a SRP-aware PoC.
Execution prevention in general might grant some protection in case a remote exploit launch intermediate executables but in case of self-contained DEP-aware remote exploits SRP doesn’t apply.
Strange that approach in itself similarly archive 0% risk as well: But another example would be assuming the user won’t need any protection if they are able to execute only code that will not infect them. :-X
Again drive-by infections might not require intermediate executables and apart from being infected, all anybody could be expected to see “are” demo PoCs.
Don’t tell me it would be possible to point you to a live exploit site for an unpatched vulnerability throughout this topic (or a newpaper article that provide enough technical detail about a malicious exploit to clarify what mitigation technologies would not apply)
Even advisories that mention when a “vulnerability” is already actively exploited in the wild do not mention any details about each one of the “crafted exploits” eventually confirmed in the wild.
The only aspects usually documented are vulnerabilities and simple PoC exploits that usually prove only single vulnerabilities whereas that’s all which is needed to have vendors provide a fix which reduce the specific risk to 0% for patched apps…
On the other hand malware authors instead do not have demonstrative purposes and are not limited to single aspects (like research PoCs):
Whereas the availability of DEP demonstrative bypass is common knowledge and reliance on SRP focus only on exploits that launch intermediate executable, DEP+ SRP are not unlikely to fail provided the victim cannot control what exploit a malicious website provides to them (of course LUA and sandboxing might be fit to overcome or simply mitigate eventual breaches)
Perhaps exploiting LUA is less common but privilege escalation vulnerabilities have been documented for years. Considering Malware authors can reasonably assume DEP to be enabled on windows services by default and that such vulnerabilities could be exploited by remote, Inbound filtering would be the only way to prevent such scenario (whereas LUA + SRP + DEP might not do anything).
Local privilege escalation of system services would be specifically meant to bypass LUA and patching the vulnerability would probably be the only practical solution (whenever execution prevention could be considered a theoretical alternative).
These aspects aside there is no doubt DEP + LUA + SRP would reduce/mitigate drive-by risks.
Glad you considered a contingency plan in case this approach get you infected: There is no need to launch an executable from non-reputable source for that though.
Besides would it be there any point to knowingly run harmful executables at all? ???
Of course many dodgy sources can be easily recognized and not running such executable might be a sound baseline approach:
But as much it might appear similar nobody can assume that the user will only launch harmless executables (or for some reason choose launch harmful ones in a containing environment) by rule of thumb whereas this begs the question about recognizing reputable sources or executables (I didn’t notice any mention to any kind of whitelisting )
Of course if anybody would be able to distinguish whenever any file is malicious by simply looking at it (or its sources) sure there won’t need to be taken any risk to execute them.
Some tools or approaches can be used to get an idea about new executables whereas the user has no prior knowledge about the sources (eg a new brand or a vendor or site previously neglected) like looking at what an executable does in a controlled environment before running it unconstrained:
VM and sandbox detection make this approach less trivial though, whereas online scanning might not identify all malware (above article mention a backdoor in in a consumer grade application publicly available for years).
Of course in doubt it would be possible to keep such application always in a constrained environment (eg VM) but this IMHO makes for a cumbersome approach unfit for daily usage and even betting onto reputable-looking applications could easily appear a more attractive solution than that.
Yes every software has been bypassed and bypasses are fixed fast but as far I see to prevent remote exploits Chromium might as well be effective as LUA+ SRP+ DEP+ SBIE.
