June 08, 2011 APPLICATION WHITELISTING

Application Whitelisting

Application Whitelisting is portrayed by many as the future of anti malware.  The idea is, if I can make a list of all the files on my computer that are ‘legitimately’ there, storing something that will help me clearly identify if they have been ‘illegitimately’ changed, then I can discard anything else and I can also immediately find out if one of my legitimate files has been modified and I should not use it.
According to Wikipedia, “an emerging approach in combating viruses and malware is to whitelist software which is considered safe to run, blocking all others. Some deem this as superior to the standard signature-based antivirus approach of blocking/removing known harmful software (essentially blacklisting), as the standard approach generally means that exploits are already in the wild.

But Wikipedia also continues :- These products may provide administrative control over program whitelists in addition to preventing introduction of new malware,but they cannot stop exploitation of existing processes in order to gain root (and therefore bypass/disable the whitelisting application). An example is provided to illustrate how this approach can’t really stop exploitation of existing processes.

So, while whitelisting sounds like a very nice idea, and, in principle, could well be the future of anti-malware, it does have its limitations and drawbacks.

I want to try and offer some thoughts about them, for those enthusiasts who push this as the absolute future of workstation protection.

Limitations and Drawbacks

In general, when you try to protect something by running the protection on the same something you are trying to protect, you are bound to be subjected to the very issues you are trying to prevent.  In other words, we are trying to protect Windows OS from malware intrusions which exploit Windows vulnerablities.  But, we run the protection application on the same OS; hence, our protection will suffer from the same vulnerabilities and issues which we are trying to prevent or protect.  Seems a bit too obvious that we will have some problems.  In fact, one of the first things any malware will try to do will be to deactivate the antivirus.  I imagine that once whitelisting becomes mainstream, new malware code will try to find its way around that as well.

To understand possible further issues hidden in whitelisting, we need to understand a bit of the details of how it works.

Obviously, we can’t simply create a list that says “explorer.exe is legitimate”.  Anyone can write malicious code and call it explorer.exe, and replace with it the legitimate one.

So, we need something else.  The most common identifier is an MD5 signature.  This is very common also in antiviruses; it is a unique identifier, created with a common algorithm, which will uniquely identify a file.  We could also add the size of the file to the signature, to be sure we have more than one element to recognize it.  So basically now we are building signatures, simple once based on MD5 hashing and expected file size; but still signatures.  Whitelisting now becomes nothing more than antivirus signatures, only made for legitimate files rather than for malware.

Let’s think of the drawbacks of this.

These “signatures” will need to be kept “somewhere”.  If we are keeping them on the same computer, how long will it be before malware starts attacking this list, changing it so that the malware itself can replace a legitimate file and not be caught?  All it needs to do is rename itself properly, and change the appropriate entry in the list with its own size and MD5 hash.  Yes, this is not simple.  In theory the protection would fire _before_ the malware can do this and would protect the computer.  But this is the theory.  In reality the possibility exists that malware might be able to modify that table of protection, and at that point there would be no protection anymore.

Another issue is, how often should that list file change and how big will it be?  Think of Windows 7 for example; Microsoft releases new patches every month.  These patches modify files on your system, every month.  So every month you have a new set of files that have changed.  The MD5 has changed, the file size has changed.  The signature list needs to be changed as well.  The size of that signature file will continue growing, as every single legitimate executable file in every single computer will need its own “signature”.    This is a list that is rapidly growing to millions of lines.

To overcome both issues (size and the possibility of overwriting) some providers are offering this as a cloud file.  So the signature files are no longer on your computer.  Which means, you’d better have a live internet connection every time you need to open a new file.

In substance we are replacing long signature files for malware, with long signature files for legitimate applications.  For now the latter are smaller for the first – for now.  But the list is growing rapidly, every month with every new update from Microsoft, Adobe and the likes.  The “size” advantage is rapidly dwindling.

The only real advantage that remains is that this is a ‘take no prisoners’ approach, which is probably what we really need against malware.  I give you a list of legitimate things, and that is it!  Everything else is considered dangerous until proven otherwise.

Will this approach truly replace the traditional AV?  Some say yes.  I continue to be skeptical, simply because I know that sooner or later hackers will find a way around this as they continue to find ways around new antivirus techniques.

My best guess at the moment is that both techniques, and some others that are already emerging, will become common weapons in the daily war against malware; and we will be using all of them.

In the mean time, hackers continue to strike (see the Citibank hack just announced) and we continue to put off fires.

Photo by AltumCode on Unsplash