May 01, 2004

Why don't we ship HIDS-like protection by default?

In the midst of the ever so exciting war between Bagle and Netsky perhaps we should reflect again on the reasons for the success of Windows virii beyond the already discussed pointless existence of anti-virus software.

It is pretty clear that most virii are "successful" by subverting some part of the system they are about to infect and gain their entry mainly via social engineering. We can discuss to our heart's content whether the techniques are getting any better but the bottom line is that "oops, I clicked on the attachment" is still leading the pack.

Instead of a pointless long rant on anti-virus software let us consider how the problem could be at the very least mitigated.

Let us assume that we can't change certain software, for example Outlook. Why? Because the Microsoft group which writes Outlook, Office and everything else is separate from the underlying Windows OS group to a certain degree. So we need to work at the OS-level. Let us also borrow techniques from various places.

To begin with let us consider systrace (by Niels Provos, originally surfaced in OpenBSD) which verifies that the system calls made by an application match those defined in its "profile". Despite sounding difficult this mechanism is in production use on many OpenBSD and NetBSD systems. In practice this means that if your Outlook tries to write to the registry a systrace equivalent will terminate it and print a suitable message. Where are the profiles? Well, that's simple, when you certify your application to run on Windows you also submit a profile for inclusion with the OS release or you add it to your installation disk.

That is already a good start, what next? Well, systrace can of course be circumvented so we need multiple layers of defence. So let us consider a limited form of "real-time Tripwire". This is a system which would very simply protect a small number of files from alteration. Allegedly this is already available under Apple's Mac OS X and is a brilliant idea. Writing to these protected files can only take place if the user authorises it, not just with an "OK" button, which is often pressed without reading the warning which accompanies it, but by typing in the user's password.

Now what is really missing is some sort of "process watcher". This would simply check that any process started belongs in a whitelist of allowed processes, not just via the process name (too easy to falsify) but also via checksumming techniques, perhaps linked in with a full version of Tripwire and friends.

Of course there is a downside to all of the above: what about the so-called power-users? Well, they will complain about the "performance hit" to which the obvious answer is "buy a bigger box". It isn't like CPU power is an expensive factor in today's PCs. The only real losers from the above are developers: for them each compiler run will produce an executable which is not recognised by the system, which they will have to register and profile.

Are we there yet? Well, the tools are mostly there, the "miracle security cure" offered by Windows XP SP2 (aka: non-executable stack) is a start in the right direction but clearly not enough. It protects from buffer overflows but not much else and the current crop of fashionable virii are not going to be affected by it.

To tie it all together one could argue that the above functionality is really beyond a HIDS and closer to anti-virus system but there is a rather striking difference: all the above is based on white-listing, allowing only what is trusted, this means that you need not download new signatures on an hourly basis but on the contrary define what is acceptable and sit back.

As a final aside one should really mention the much-hated Trusted Computing Platform Alliance which got it all wrong by associating their work with so-called "Digital Rights Management". An overview is available on the Wikipedia, for discussions of how a much needed idea was turned into a nightmare see Ross Anderson's FAQ on the subject and the EFF's white-paper titled "Trusted Computing: Promise and Risk".

What is needed is a push, on the part of users, towards OS developers to implement some basic security features which would make life much easier for all of us.

Posted by arrigo at May 1, 2004 12:30 AM