Why I Don’t Like Anti-Executables

A somewhat new method of security systems is the anti-executable. The idea is that you only allow the programs that you trust to run and, by default, everything else can not run. There are a few problems with this.

The Principle

I believe that security can not be ‘noisy’ or ‘interactive’ ie: the user can’t be burdened. Anti-executable is a tool designed for user interaction. A strong policy restricts software, a weak one restricts users. Anti-executable does both.

Usability IsĀ Nonexistent

As I’ve said above an anti-executable program will burden the user. Users have to directly interact with it and therefor it’s a major pain. Any time you try to run new software it will be blocked. The average user would hate it.

This, of course, means that it’s wide open to social engineering. Users don’t trust the anti-executable to make decisions as it makes no attempt to do so therefor an attacker really only needs to trick the user. If a user has already downloaded the file they obviously trust it.

Of course, that still leaves drive by downloads…

It Just Doesn’t Work

Even for driveby downloads the anti-executable is only effective in a world where hackers don’t pay attention to it. This is not like a sandbox where a hacker has to either rethink their entire attack method or come up with multiple new exploits for escalation – an anti-executable means pretty much the same game plan but with a few slight hurdles.

Programs create new code in their virtual address space, it’s how they work. Your browser couldn’t open new tabs without this, Chrome couldn’t create a new process, etc. Any attempt to stop a malicious payload from hanging out in a processes address space would completely break every program. The approach they take, I don’t know, but I suspect they make use of a few API calls, which they intercept like onopen or potentially virtualalloc.

All exploits start out in the virtual address space anyways so the hacker doesn’t have to take any extraordinary steps here. They’ve just overflowed some buffer or whatever, they’ve created their ROP chain, and now it’s just a matter of either stealing what they need and getting out or, if they want persistence, they can hop to other processes (apparently quite easy to do) or use some other technique to write to the disk.

Conclusion

An anti-executable is, at best, a half decent layer of security. It sorta kinda attempts to prevent persistent malware but I can’t see it being too effective. Current anti-executables have already been bypassed multiple times in POCs but I’ve only seen one malicious exploit that stays in RAM using reflective DLL injection if I recall correctly.

If you combine something like a sandbox and other strong policies with an anti-executable I suppose it could be worthwhile but at the moment the only reason it’s so effective (at preventing drivebys) is due purely to the fact that no one uses it and hackers don’t really care about it.

I mean, yeah, it’s better than nothing. But if you have to say “better than nothing” about something it says a lot.

P.S. I hate outbound firewalls for this reason too. Process A can create a thread in process B (lol windows) and I really don’t know how a firewall that blocks A but allows B is going to do a thing about that. That and user interaction is poor security. Outbound firewalls are also a half decent layer but if the malware is already on your system, potentially with root, you’re quite likely screwed.