Given my recent (and probably ongoing) adventure with the authors of RkUnhooker, I thought that I post my opinions about the whole rootkit – antirootkit business.

To put it bluntly: it doesn’t (or shouldn’t) matter at best and it is a misguided effort to stear up hype in which many people participate without even realizing what they are taking part in at worst.

Why do I have such a low opinion about the matter? Because this is the DOS virus wars all over again! Back then you got one (tiny by todays standards) common memory space where each program was placed with no built-in protection to keep them apart. Back then both viruses and anti-viruses raced to make a better, smarter, trickier product which was harder to kill. Very important: harder, but not impossible. In the end there was no definitive solution for the problem since there was no third party supervisor which would have had the responsibility to keep programs separated.

And along came protected mode and the operating systems using it and this problem was solved almost overnight. Now there was a clear and very strongly (by hardware) enforced separation of programs (at least in user – also referred ring 3 – mode). What’s nice about this that as long as you keep your programs in ring 3 and don’t allow them to access ring 0, you can retain full control over them. Think about it: full control. No dirty hacks, no cat and mouse games, full control for now and for ever!

On the other hand if you let any untrusted code in your kernel, you’re back to step 1: the DOS era. Now you’re back in the era of cat-and-mouse games and smart tricks which work only until someone outsmarts them, you have no guarantees whatsoever regarding them and what’s the worst is that you might not know that somebody outsmarted you for a very long time. Again, contrast this to a protected mode architecture where you keep the programs where they belong – in user mode: there is a clear separation of privileges and you know that your kernel mode component is and always be safe.

Rootkits are only the first generation. They are an evolutionary step which appeared because malware writers wanted the to access advances of the kernel mode without rewriting their existing codebase which was traditionally usermode. And so the things called rootkits appeared. After rootkits gained a certain notoriety, of course tools to detect them appeared. However, most of the tools are reactive in nature, meaning that after a new technique is introduced, some time needs to pass until a detection for that certain technique is added. And we’re back to the cat and mouse game with no possibility to predict how fast a detection for a new technique will be added (because any prediction must factor in the time until discovery which can not be predicted).

What is even worse is the fact that the next evolutionary step of malware is to run fully in kernel mode. In the case of such malware 99% of the current tools become useless (because there is no anomaly between user and kernel mode, because the code runs just in kernel mode – so the cross-view style detection is out of question – and the patch detection ones also have a dubious usability because the kernel-mode malware code doens’t have to patch anything, it can run just as any normal kernel code, using the documented interfaces). Even more, the malware can patch data (function pointers for example), not code to make sure that it gets executed, making its detection very improbable. And we still have the basic problem of the malware and security product executing on the same privilege / trust level which again results in a cat and mouse game.

In conclusion: we have a perfectly fine solution for the rootkit problem – it is called limited privilege users, the kind which can not load any code into the kernel. It delivers predictable results (no rootkits) with a very high probability reducing the risk to an infinitesimally small number. Why not use it?