Trusted Path Execution And AntiExecutables

A user commented on my guide for compiling the Linux kernel with Grsecurity and PaX patches and brought up Trusted Path Execution. I somehow missed this feature and I’d like to comment on what it does because it’s relevant to a conversation on another forum about Anti-Executables. So I’m going to look at  TPE and go a bit more in depth about why I don’t find AntiExecutables to be useful for home users.

TPE is, essentially, an antiexecutable. There are three options:

  1. Partially restrict all non-root users.
  2. Invert GID option.
  3. GID for (un)trusted users.

1) Partially restrict all non-root users

Essentially this option stops a program of user ID X from executing a file owned by user ID Y. If a file is owned by root and only root can write to the file that file can be executed.

It seems like a fairly cool feature. What I like is that it enforces a consistent policy – the program that downloads the file is the program that can execute the file. It makes sense and it doesn’t get in the way as this behavior it enforces is the typical behavior a user should observe.

2) Invert GID option

The Invert GID Option changes the ‘GID for untrusted users’ into ‘GID for trusted users’ ie: it flips from a blacklist to a whitelist.

3) GID for untrusted users

Essentially if the GID is set to X then X can’t execute any files. If 2) is set to * and it’s really GID for trusted users then only X can execute files.

I Don’t Like AntiExecutables

Antiexecutables are fine for enforcing policies in the work place. If an IT Admin decides users can only install Word and Adobe Reader they can use an AE to enforce company policy via software policy. It’s great for this because the user does not own the machine and can not bypass the policy.

On a users machine the user is the boss, not the AntiExecutable. They can bypass these restrictions easily.

In neither of these situations is the AntiExecutable stopping an exploit from being successful. An attacker can do just about anything they’d like from a “RAM-Only” attack (ie: a remote code execution that never drops a separate executable file) as they can by writing to the disk. When you drop a shell into Reader.exe you inherit all rights of Reader.exe because you are Reader.exe – you live in that processes address space. So if Reader.exe can create a startup entry then, surprise surprise, so can you. And there’s your persistence since so many people believe that persistence is not possible if one uses an AntiExecutable (the issue of persistence can be more complex depending on the policy, but in my opinion if you’re relying on any traditional AE on its own persistence won’t be difficult to achieve).

An AntiExecutable doesn’t really make things much harder for an attacker. The way attacks typically work now is that you get shell and then you download and execute a new program. This is great because you can switch up your exploit and keep the same payload or you can switch up the payload and keep the same exploit. Either way, it makes things more flexible from a managerial standpoint and does virtually nothing to make things more difficult from an attack standpoint.

Again, if a clean program can do it the hacker who exploits that program can do it. If reader.exe can write to /path/to/x so can the attacker.

And this is why I wouldn’t bother with anything too crazy with AntiExecutables. I think the ‘Partially Restrict All Non-Root Users’ is great because it reinforces some common sense policy. That’s as far as I’d be willing to go – it does not really add significant security, hackers can do it all in RAM from their initial RCE.

On a server you don’t need flexibility and piling on security is basically the best thing you can do. Go ahead and use an AE – use anything, really. If you’ve got a Sys Admin sitting there watching logs then seeing access violations through the TPE could be a really strong indication that you’re being attacked. I leave that to the IT’s judgement here.

As a user you do need flexibility and convoluted policy can even make you less secure. You open yourself up to social engineering (yes, there are different levels of vulnerability here and different programs make you more or less vulnerable) and you complicate your setup. I don’t think TPE is really going to hurt you (especially the partial restriction) but it can be annoying without any real reason for use as a user.

Personally I’ll be using the partial restriction. Why? Not because I think it’s really making me a whole lot more secure… purely to see if it gets in my way and kind of a ‘well I may as well’ thing. I rely on the other security measures in Grsecurity to keep me safe and there are more than enough features in that patch to do so.

So, the conclusion here is simple, if you’re on a server pile it on. If you’re a user just use the ‘partially restrict all non-root users’ option. And, above all else, remember that neither of these should be relied on.

Edit: And as Brad Spengler (creator of Grsecurity) aka Spender has noted there are multiple other techniques implemented by Grsecurity that work with TPE to create a strong system. Grsecurity is obviously a very powerful set of patches and TPE is only one of many features.

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.