Race to zero
The Race to Zero is a competition which recently wrapped up at Defcon. In it, teams of contestants are given ten known pieces of malware – viruses and exploits – and are tasked with obfuscating the malware in such a way that antivirus programs cannot detect the malware. The competition was ultimately won by Mandiant which completed the task in a little over six hours. (About 36 minutes per challenge). This contest simply serves to illustrate the point that signature based antivirus scanning is a failing proposition. As I’ve said before, there are a virtually infinite number of possible malware signature out there, and trying to write an infinite number of signatures is an exercise in futility. It makes a lot more sense to enumerate good than to enumerate bad. We figured this out years ago when we started making firewalls use a default deny – we should be doing the same for antivirus.
Tags: antivirus, defcon, malware, race to zero, virus
August 12th, 2008 at 7:58 pm
i’m afraid your logic is fatally flawed… the number of ‘possible’ good programs is equally infinite… this is why nobody bothers trying to make lists of what possibly might be created, instead only making lists of those things that actually have been created…
further, as has been reported by whitelisting company bit9, the number of ‘actual’ good programs outnumber ‘actual’ (as in they exist right now) malware by several orders of magnitude and is growing far faster than ‘actual’ malware is…
August 13th, 2008 at 8:28 am
The number of possible good programs may also be infinite, but the number of good programs running on your computer is significantly smaller. Think of the parallel example from network firewalls. There may be an infinite number of possible network applications people want to run, which is why we let people configure their own firewalls. People open up only the ports they actually want whitelisted and drop the rest. Do the same with antivirus – implement a default deny and let users/administrators whitelist the activities they actually want.
August 13th, 2008 at 12:18 pm
the user-editable whitelist, where the user rather than the vendor decides what to authorize is indeed the only in which the whitelist can be smaller than current blacklists… unfortunately it puts the burden of deciding what’s safe on the user… whitelists are not static – new software gets added and existing software gets updated and each time this happens the user needs to know whether the program(s) they’re adding to their whitelist is safe or not… the most likely way average people are going to deal with the uncertainty inherent in such a situation is to check the program against a blacklist before adding it to their whitelist but then the whitelist is no more accurate than their blacklist…
additionally, application whitelists only block the execution of those things they recognize as programs… not all programs are *.exe files, some are far more exotic and may traditionally be considered data (ex. ms word macros)… whitelists can’t block the execution of all possible program types because that is yet another infinite set, they will typically only block execution of the more mainstream program types and you may be surprised how narrowly defined that set is (ex. the application whitelist functionality in sunbelt personal firewall doesn’t block batch files)…
August 20th, 2008 at 1:10 pm
You’re making a lot of assumptions, the first one of which is that I’m satisfied with current commercial offerings. Suffice it to say, I’m not. If current commercial offerings only handle .exe files and not other executable formats then that is an obvious flaw in the implementation which should be corrected and it does not suggest the principle is unsound. Secondly you’re too hung up on whitelisting specific applications. There are a lot of places you can apply filters. What if you looked at API calls? Or network traffic? Or registry calls (for windows machines)? You will notice if you read the blog that I’m not very concerned with specific tools but rather with technological approaches in general. Tools come and go, it’s the underlying principles which matter.
September 23rd, 2008 at 12:57 pm
sorry for responding a month later – the system i was using to track comment threads flaked out silently…
about your 2 points:
1) you may not be satisfied with whitelists that don’t include all program types but that’s not an implementation defect… it’s theoretically impossible for it to include all program types from a computer science standpoint… there are an infinite number of them because all data has the potential to be interpreted as code…
2) there are similar limitations for everything else you are suggesting, be it API calls, network traffic, etc… there will always be ways to accomplish these things that a filter won’t recognize… this isn’t a matter of implementation, it’s a matter of computation complexity and computability…