the whitelister's dilemma

you remember marcus ranum's 6 dumbest ideas in computer security? #2 on that list was enumerating badness (aka blacklisting), which he believed should be replaced with enumerating goodness (aka whitelisting).

ignoring the fact that his underlying assumptions about relative sizes of the malware and legitimate software populations was incredibly wrong*, there's a much more fundamental problem with turfing blacklisting in favour of whitelisting:

the only meaningful criteria we have for deciding something is good or safe is that we haven't found anything bad in it yet.

oh sure you could assume that a system is currently malware free and start your whitelisting regimen from that (potentially pre-pwned) state. you could assume that software direct from the vendor is safe to add to a whitelist too (because microsoft never accidentally distributed infected materials, right?). you could even assume that things that are digitally signed are safe (it's not like stuxnet was digitally signed or anything).

of course, we know what happens when you assume. the reality is that even if we do adopt whitelisting we have to continue enumerating badness for the purposes of maintaining the whitelist. whitelisting stands on the shoulders of blacklisting - it has to, our only other criteria are assumptions that have all been proven false in practice.

as such, whitelisting can never replace blacklisting, it can only ever complement it.

[* according to figures by whitelisting vendor bit9 that i mentioned here, and frankly the idea of a malicious few coders out-producing the benign many seemed silly anyways]

general purpose, what's it good for? absolutely too much

here's a blast from the past. over at tenable security blog this article from january by marcus ranum discusses the possibility of developing special purpose computers for the sake of online banking.

he comes to an interesting conclusion that we may be seeing a market develop for non-general purpose computers but what we have to keep in mind is that it is not the operating system that determines whether a machine is general purpose or not - if we want special purpose machines we have to start at the hardware layer. i know some people find it hard to believe that it's not the operating system that enables malware to be a problem but to demonstrate that that is indeed a fact let's look back to the old bootsector infectors: viral malware which executes and infects before the operating system is even loaded into memory, using nothing but the hardware API's. clearly, generality transcends the OS.

in order to produce a machine which is guaranteed malware free (in order to use as a trusted endpoint in online banking) we have to address either the generality of interpretation (which most people don't really understand, but which is the cornerstone of general purpose computing) or the sharing of data (which would be counter to the design requirements of any system that needs to communicate with another system - such as an online banking dumb terminal). those are the 2 key elements of general purpose computing that enable malware to exist, and since we can't really get rid of sharing for the application in question that just leaves getting rid of the generality of interpretation in favour of fixed first order functionality.

the consequence of doing this (creating a radically different hardware architecture that only allows for fixed first order functionality) means that we can no longer use commodity hardware. that means we would no longer enjoy the benefits of commodity hardware pricing. that in turn means that the cost of ownership of one of these dumb terminals will be rather high compared to commodity computing counterparts. i don't know if the theoretical market for such special purpose computers can withstand the practical realities such a device would entail.

marcus ranum has found his saviour . . . or so he thinks

marcus ranum has finally found an execution control app (in other words application whitelisting software, the likes of which i've written about before) that he's happy with and apparently thinks could be the final nail in the coffin of anti-virus software - read it here...

yes, marcus is one of those people who thinks anti-virus is dead, or if it isn't it should be... he's taken shots at it before under guise of the stupidity of enumerating bad things instead of good things (nevermind the fact that there are far more good things in the world than bad) and in the above article makes reference to it as being an "default permit" technology... clearly, marcus likes to think in firewall terms...

despite that, calling anti-virus a "default permit" type of technology is a rather gross over-simplification... anti-virus software doesn't permit things, it deals with what it knows and what it knows is bad things - when it encounters one of those things it alerts you to the fact so that you can try to protect yourself from it and/or don't inadvertently do something dumb... what you do with everything else is entirely up to you, it's not anti-virus software's business to get involved in that... simply put, anti-virus software is a type of blacklist technology...

now, it shouldn't take a rocket scientist to figure out that blacklists and whitelists actually complement each other, especially here... yes, only allowing known good applications to run is more secure than simply filtering out the known bad ones, but how do you determine which ones to allow? predefined blacklists and whitelists provided by people with expertise allow us shrink the scope of this problem by reducing the number of things we'd need to determine the safety of unaided - but marcus would have us throw out one (or both, considering his reaction to prevx) sources of anti-malware intelligence and figure that sort of thing out for ourselves...

maybe i'm wrong, but i think most people use computers to get useful work done, not to waste their time researching whether executable X is good or bad when that information is often already available in downloadable form... most people aren't very good at that anyways (if they were the malware problem would never have become a big problem) and marcus is clearly no exception since he needed software to tell him that windows probably wouldn't operate properly if everything under the windows directory were denied the ability to execute...

when deciding what's ok to run the user needs help, especially with windows... microsoft has put a lot of magic into windows, by which i mean there's a lot going on behind the scenes that they make absolutely no attempt to be transparent about... without expert knowledge it's hard to know which of the hundreds of executables that get included with windows needs to be allowed to run in order for windows to operate properly...

marcus has apparently learned his lesson about the windows directory, but clearly not about the importance of making use of intelligence that has already been gathered... also not about knowing the enemy, and not about knowing oneself - by which i mean he appears to have not considered the weaknesses of application whitelisting technology... there are, and will always be, types of executable content that application whitelists won't be able to recognize (for example, new scripting languages won't be recognized by old whitelist software)... there are, and will probably always be, ways to get software that has already been authorized to do your dirty work for you (for example, internet exploder combined with some of those improperly labeled safe-for-scripting activex controls - or even buffer overflow exploits)... execution control software has a fairly limited notion of how execution can happen that doesn't actually reflect reality - most of the standard ways it can handle but would it have saved you from a WMF or VML exploit? would it have prevented macro viruses from ever becoming a problem? updating a blacklist to catch these things is relatively straight forward since you're just telling it additional things to look for, but updating a whitelist to deal with them involves making additions to how it looks for things being executed...

whitelisting is not the great stand-alone solution marcus thinks it is... it's a great complement to an anti-virus application, though, and an excellent technique to apply provided you can deal with figuring out what's safe to authorize...