The Death of Anti-Virus: conference paper

DAC - the process decides its rights, runs with the rights, etc; access control at the discretion of the process. MAC - the administrator sets down rights as law, processes must abide by them.

Privilege escalation is something that has been dealt with extensively and is very costly. The techniques to prevent it are not implemented, that is all. It is also a very complicated issue because it depends a lot on the sandbox and the attack.

On a properly set up Linux system it is completely unreasonable to try to escalate privileges from a locked down sandbox (and it will continue to get harder, sandboxing is going to continue to improve on Linux). It is simply too difficult for anyone outside of massively funded organizations, like a government, or very very large corporation that can afford to buy dozens of zero days and hire full teams to write attacks.

In terms of comparing default deny to MAC, default deny requires no new vulnerabilities in order to be bypassed. MAC is always +1 vulnerability, and, when implemented properly, it's +1 vuln with reduced attack surface.

You're basically just describing limited users here. This is far closer to a sandbox than an antiexecutable.

 

I have some sysadmin friends who might disagree. Secured Linux servers get rooted all the time.

(Desktops are another matter, but remember that Linux still accounts for what, less than 3% of desktops systems?)

To be fair though, most HIPS do more than "default deny." If you put e.g. PrivateFirewall in learning mode, it's probably building a catalog of executables, and the minimal set of privileges that each one requests. Disable learning mode, and it will query you whenever something tries to go beyond those minimal privileges.

(Which is actually my main problem with most HIPS - they query the user, which is stupid. Policy violations should be blocked and logged, with noninteractive notification. Let the user look at the logs later and figure out what happened, if need be.)

 

Your sysadmin friends probably aren't doing a ton to secure it against those types of attacks. I sympathize with them, I have had to secure linux server systems and a lack of vanilla support for security makes it difficult. Local attacks end up being the most difficult to stop because you're too busy focusing on uptime, remote attacks, and just getting things to work - dealing with kernel security when you have to compile a secure kernel is a pain.

There are *very* few privilege escalation attacks that will work on a hardened system. Minimum of an information leak required, typically multiple separate vulnerabilities are needed.

A problem with terminology like HIPS and AE and AV is that they have been turned into marketing terms. It makes it hard to differentiate between something like a sandbox and a HIPS.

 

I'm quite a bit agree about this point.

Rely on demand scans I can chose to delete them, test them or believe to use them. Also I can have more type of on demand virus/malware scanners. With that way I can dodge away from false positive from realtime AVs. Beside these virus cleaner are still use the same antivirus, Intersecurity's virus database engine which detect the same results.

ps. In fact i cannot even decide to install which realtime AV though. I've collect too much real-time AVs to decide it.

 

I take it your definition of "hardened" involves PaX/GrSec + MAC. Nothing wrong with that, but yes, deploying such setups on production servers can be a nuisance.

Also a lot of services are deployed through VMs these days; I know people who do that on home servers. I don't know how GrSec plays with virtualization, but I suspect the answer is "not nicely" (c.f. Xen vs. SELinux).

Usually the answer can be found in a product's GUI. Most HIPS software has extensive configuration options for different restrictions - not anywhere near as extensive as e.g. AppArmor, but enough to give one an idea of its capabilities. The HIPS programs I've looked at have almost all been able to restrict things like registry and filesystem access, IPC, and library loading.

(Or at least claimed to be able. Can't say whether such things are implemented well.)

Edit: for example, Outpost Free 6.51:

http://img715.imageshack.us/img715/3649/93063327.png

That's... pretty limited, but it does more than just block process spawning.

 

My definition of hardened would go a bit further than that, but that is certainly involved.

Grsecurity works fine with Xen, except for Udref.

The point is that the future of security should be following sandboxing. Privilege escalation issues are largely dealt with already (cost is way high), just not in a standard way.

 

UDREF? Oh, this:

https://www.atomicorp.com/wiki/index.php/ASL_3.2_Virtualization_Notes#Xen

Thanks, I didn't know about that.

Anyway, do check out the Outpost screenshot above, that should give you an idea of what's typical for HIPS. Not sure how good any of that is though, I know very little about the Windows API.

 

The thing is that HIPS just means Host Intrusion Prevention System. That's a fairly vague term.

 

On subject of AV labs doing analysis by hand, I remember at one time Kaspersky Lab analysts were called woodpeckers, simply because of the amount of keyboard tapping you could hear as they set to work.

 

Not including the OS and the specific enforcement tools being used, it would seem that the biggest difference between our approaches has been differences in terminology. I've viewed it as default-deny being applied on a system level. You describe it as limited user and a form of sandboxing. I guess my setup could be viewed as using SSM to creating a limited account. I guess it could qualify as something of a policy sandbox as well, although I didn't approach the issue from either of those positions. With SSM, I started with the maximum restrictions available on each process, then only allowed what was necessary for that process. What you called least privilege and what I was calling minimum permissions are much the same thing, just enforced by different means.

This whole alphabet soup thing drives me nuts. Too many of them have overlapping or multiple meanings. HIPS can be almost anything any more. VPC and VirtualBox technically qualify as Host Intrusion Prevention Systems. When I beta tested SSM, the term HIPS didn't exist. Terminology and their definitions have been problems since at least the 9X days, especially with security software. Remember way back when AVs detected viruses but didn't detect most trojans? Or specialized anti-trojan apps didn't detect worms? Or the controversy and lawsuits over "adware" and "spyware" and the lack of official definitions for either? Those of us who fought CWS or the bundle that came with Kazaa had other more descriptive definitions for them. The biggest part of the problem was that there were no concrete definitions for any of the undesired code. The vendors wanted to create artificial distinctions or lines between them. The result was malware being missed by all of them. Nowadays, most of it can fit into most if not all of the categories. Instead of playing the name game with malicious code, marketers play it with the security software. As usual, the typical user is the one who loses.

 

I think the largest discrepancy between our approaches is where the pressure is put. I'm fine denying all system calls to a developer and having the dev have to state they need each one. I'm not fine allowing the user to make that decision, or having the pressure be on the user to.

I believe the pressure should be on the operating system. I believe that when it can't be on the operating system it should be on the developer. When it can't be on the developer, there's a problem.

But yes, due to terms being conflated for marketing reasons, it's annoying to try to discuss things sometimes.

 

There's the need to those who need them. But if we're going to the extreme level, on-demand scanners and even online file analysis services are also not needed.

I've used and seen many software, be it security software or not, which uses more system resources and slowing down the PC than any big name AVs I've tried. In most cases, AVs are not that monstrous.

 

It depends heavily on the hardware. Current versions of Norton AV work fine on a Core i5 machine with 4 GB of RAM, but forget about running them on a Celeron with 512 MB.

BTW, I took a look at what Privatefirewall's driver does, and it definitely qualifies as MAC. The problem (as with most HIPS) is more lack of configurability.

 

I've been hearing the same thing since I really started working on computers (06 or so) that antivirus technology is on its last leg and its going to be dead. The years have past and its not come to fruition yet.

My personal belief is that while yes it is important to spread security out a bit (Behavior Blockers, Sandboxing, Anti-Executables and god awful HIPS)
I think Antivirus's will always be effective and have their place especially with as Rejzor said with new cloud technologies.

 

IMO the continued heavy use of AV products owes more to the industry's hype output than anything else.

Re "cloud technologies," what exactly is meant by that anyway? Can someone provide a definition of "cloud antivirus"?

 

AV is used because AV is easy. No one has made an easy to use sandbox or AE or HIPS yet.

Easy trumps all other things.

AV is not dying, per se. But other products that are more effective will be springing up in the next few years, and they will potentially have quite an impact on AV companies if they do not learn to adapt.

 

Roughly translated:
AV vendors will buy up new security technologies, weaken them down, then bundle them with AVs in order to keep customers continuously paying for protection that should be a one time purchase. The actual AV components are little more than cash cows.

 

That will certainly happen, and has happened in the past. I only expect that to continue. But eventually someone won't sell out, and they'll have a good enough product that it works.

 

Unfortunately we just lost one of the best contenders, SandBoxie. The original developers of what's commonly called classic HIPS are all gone. The security suite "equivalents" are mere shadows of what the originals were. Look how long it took Windows to add back to their firewall what it had from almost the beginning, outbound control. Or their half-@$$3d implementation of security features found in linux and BSD. This list is almost endless.

 

I assure you that the software that will come out in the next few years will blow away what we've been seeing lately. Sandboxie may die, and I believe it was likely purchased to be taken out of competition (just my opinion), but I can guarantee that sandboxing/ capabilities based software will come out in the next few years that will be far more comprehensive.

 

I don't miss HIPS at all and I consider myself lucky that I got to AppGuard and Sandboxie right away, so I was spared this ordeal.

 

There are much better ways to protect ones self than relying on traditional AV's, but they still have a part to play. Most of society is too lazy to learn how to use other superior technologies.

 

HM,
I wish I could share your optimism. IMO, operating systems (especially Windows) and most security packages are going in the wrong direction. Windows might be making it harder for malicious code to exploit the stack, memory, etc, but at the same time they're increasing the size of the attack surface. What they fix on one end, they weaken at the other. IMO, nothing will really change until both Windows and security software gets past this default-permit mentality. There never will be an escape-proof sandbox or jail. It's a continuation along the same path we've been on all along.

The blame for that has to land directly on Microsoft for building "no skill/sense needed" operating systems.This "do it for you" design, the very thing that made XP mainstream, became the problem with modern computing. One could argue that this is what people wanted and that it was a business decision. It might have been good for business but it has proved to be one of the most short sighted decisions they could have made. IMO, the average user should be running live CDS.

 

Computers should not be about security. They have been and i hope they always remain about accessibility - everyone deserves to be able to use a computer safely, and to be able to access the information that others have available to them.

That is why they are made "Easy" not "Secure". That's a good thing.

The problem is the attitude held that security always diminishes usability. This is a fallacy, it's simply not true at all.

 

Not to get too off-topic, but IMO computer usage will require some modicum of technical skills for quite some time.

It's recognized pretty much everywhere that e.g. driving a car safely requires a certain level of knowledge and training. I find it odd that people don't seem to think the same of computers. Sure, the effects of misusing a computer are (usually) less hazardous, but I think the same rule applies to all tools of sufficient power and complexity.

Really, when you get down to it, I think some level of training in safe computer use needs to be a public service. Not just avoiding malware, but also avoiding bogus information; not giving out too much data about yourself; not getting hooked on porn; stuff like that. Sort of like sexual education. Remember this thread? People are going to use the Internet, and they are going to be exposed to its hazards; so they should be trained from early on to recognize and avoid those hazards.

Just my 2c.