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]

digital signatures are not a poor man's whitelist

back when mcafee had their catastrophic false positive i made the suggestion that av vendors in general (and mcafee in particular) could use a whitelist of critical system files to avoid false alarms that render systems unbootable/unusable. basically the idea being that known trusted files could be ignored by anti-malware components prone to false alarm. in the comments of that post didier stevens suggested checking digital signatures of files could be used as an alternative. at first i thought that was an OK compromise to developing a proper whitelist of critical files, but recent events have made me rethink that.

as kaspersky's alexander gostev described, a digital signature will cause a file to be regarded as trusted by security software, much like didier suggested in his comment, and if it's malware that means it will be effectively hidden from the anti-malware software.


i think that's a pretty glaring problem and underscores the fact that digital signatures are a poor substitute for a proper whitelist. a proper whitelist is constructed of items that are known and trusted, but with digital signatures it's neither the anti-malware vendor nor the user who's constructing this implied whitelist. instead, the implicit whitelist is constructed jointly by every tom, dick, and harry who happens by hook or by crook to get his/her hands on a valid digital certificate. that means the people who make the determination of whether a file is safe and/or trustworthy are (generally) the same ones who created it. however, those people could lie, they could fail to actually check the safety/integrity of the file they're signing, or they might not even be qualified to check the safety/integrity of the file they're signing. even if the owner of the digital certificate used to sign the file is a trustworthy entity, that doesn't mean the file is also trustworthy. first and foremost, trust is not commutative. besides that, though, as the stuxnet example shows us, the certificate can fall into the wrong hands. treating digital signatures as whitelist entries creates a situation where altogether too many entities have influence over what is considered trusted and safe.

thus digital signatures can not tell us what we need a whitelist to tell us, namely that the file is trusted and safe. the presence of a valid digital signature only tells us two things: that the file was signed with certificate X (which may or may not be under the exclusive control of the party it was issued to), and that the file hasn't changed since it was signed. whether it's safe, whether it's fit for use, is entirely outside the scope of what a digital signature can tell us.

i think the idea of using a whitelist to avoid false alarms is a good one, but using digital signatures in it's place is a shortcut. av vendors need to stop cutting corners and implement proper whitelists for this particular application. there are already tens of thousands of digitally signed malware samples in f-secure's collection so i'm at a loss trying to figure out why this technique of false positive avoidance hasn't been abandoned already. now that news that detections of stuxnet didn't start until after the digital signature expired, malware authors will surely be looking to exploit this behaviour more and more.

whitelist opinion smackdown

i realize i've been rather quiet as of late - not sure why, perhaps i lost my mojo... anyways, you can all thank cdman for rousing this ogre out of slumber...

in a recent post, cdman lays out his response to randy abrams' post on whitelisting... perhaps it was the hint at the possibility of an ad hominem attack against a fairly well known and long-standing member of the av community (randy was, for a long time, the voice of av from within the belly of the beast - aka microsoft) that piqued my interest, but that wasn't cool so let's move on...

cdman's first substantive beef is the suggestion that whitelisting companies can't do their job without anti-virus software... ignoring the fact that in practice this is actually true (whitelisting companies currently depend on anti-virus software to determine if something is safe to add to their whitelist) lets look at the hypothetical alternatives he suggests - specifically that whitelist vendors could rely on reputation or building the generic malware equivalent of marko helenius' automatic and controled virus code execution system...

relying on reputation offloads the problem of keeping bad software off the whitelist onto the very people providing the bad software... sure people who provide bad software consistently will get a bad reputation and not be trusted, but what about people who only do it once in a blue moon? microsoft releases tons of legitimate and safe software but they have on occasion also distributed virus infected materials... you'd be hard pressed to justify not whitelisting code from microsoft if you were relying on reputation but if you did whitelist all their code you would eventually whitelist something you shouldn't have... furthermore, relying on reputation is precisely the method that customer-generated whitelists are primarily made with, which would make a vendor-generated whitelist using the same technique rather pointless...

next is the idea of building a system to automatically execute samples and perform baseline comparisons to see if the sample compromised the system... and of course this has to be done on a scale sufficient to handle the rate at which sample files are produced (otherwise whitelist vendors wouldn't be able to keep up, much like av vendors supposedly aren't able to)... but have you looked at bit9's (a whitelist vendor) figures? av companies already augment their small armies of malware analysts with automated methods of determining what's bad, and old methods like this are almost certainly among them... if the av vendors can't keep up with the malware then what hope do whitelist vendors have in keeping up with the goodware when it's production rate is (necessarily) several orders of magnitude greater than that of malware? there are all kinds of capabilities peculiar to traditional av companies that whitelist vendors could try to replicate in-house, but the scale of the samples they have to deal with make it impractical for them to do anything other than to replicate the blacklisting capabilities in full in-house and that would mean they would still be using what the general population considers av - it would just be their own...

a third option cdman mentions is using technology like that developed by mandiant... whitelist vendors are unlikely develop such capabilities in-house when it's almost certainly cheaper to buy products/services from others who've already developed those same capabilities, but lets hope in this case they stay away from such ethically questionable companies as mandiant... bad enough that mandiant hires people whose marketability in security is thanks in no small part to their past efforts at making the problem worse, but to then turn around and have some of those same people do essentially the same thing in the company's name at an event like race-to-zero smacks of not just some lapse in HR's judgment but rather of an alignment of moral compasses... perhaps i'm in the minority here, but if a whitelist vendor gets in bed with a company like mandiant i wouldn't touch them with a 10 foot barge pole...

second to the beef about what whitelist vendors would do without av software was cdman's beef with randy's understanding of what actually constitutes a whitelist... i have to admit that my first impression on reading the statement that the TSA implements a whitelist was one of confusion... the most widely known (and reviled) measure the TSA implements is the no-fly list, which is fairly obviously a blacklist... i actually left a comment on randy's original post expressing my confusion but literally as i was writing it it dawned on me that there were other measures implemented by the TSA such as the newly revised rules for flights which basically require one to be granted permission in a 2-stage process before you can fly... of course, as i write this i'm reminded of the various trusted traveler programs that schneier has written about on occasion - those are also whitelists...

despite all the disagreement, though, in the end cdman and randy are actually in agreement about the role of whitelisting - it's simply another layer... both think it's got it's strengths and it's weaknesses, areas where it's more applicable than others, etc.. however, i think randy has once again distilled a complicated topic to a simple analogy when he compares the folks who say whitelists are the end of av with airbags calling seatbelts obsolete... what a clever way to say they're full of hot air...

symantec's reputation is in the clouds

the folks at symantec posted something interesting today - It's All About Reputation...

well, they're not the first ones to go into the cloud (obviously, see panda, trend, mcafee, etc)... nor are they the first to go with a reputation system (drive sentry, for starters)... are they the first to put a reputation system in the cloud? i don't know, maybe, but at this point it still doesn't seem like such a big deal...

what gets me, though, is the idea that it's no longer using fingerprints... a reputation system that says X is good, Y is bad, and Z is unknown is basically just a combination of a blacklist and a whitelist - and it's not a bad idea, i've been saying they complement each other well for quite a while now so actually putting both paradigms into a single product makes a lot of sense... the blacklist is what says Y is bad, the whitelist is what says X is good, and since Z isn't on either list it gets called unknown... the thing is blacklists use signatures (fingerprints) and in their own way whitelists do to - they have to in order to make sure the thing you're looking at really is the same thing you saw before and determined to be good/bad... it can't work without a signature/fingerprint/whatever... this new reputation system may use a different form of signatures, but it definitely uses them...

and as for how this protects you from brand new threats as the post suggests, i can only imagine it works like this: things on the blacklist are stopped from executing automatically, things on the whitelist are allowed to execute transparently, and things that aren't on either list will cause the user to be given an "are you sure?" prompt... finally, someone's putting dr. solly's perfect.bat (which asked the user if the file being scanned was a virus or not) to good use...

the other way it might work is that the unknowns get automatically run in a sandbox of some sort... not a sandbox meant for malware classification, mind you (a number of products already do that), but a sandbox intended to separate the handling of untrusted items from the trusted host system... i mean, since they're already adding 2 of the 3 preventative paradigms into a single product (hopefully seamlessly), wouldn't it be cool if they added the 3rd as well? i won't hold my breath for them actually implementing this, though...

chrome plated security

seems like everyone is talking about google's new browser called chrome... google even made a comic book about the product...

the comic describes a lot of what went into chrome and it sounds like google made some very interesting design decisions, like making it a multi-process application instead of simply multi-threaded, or their new javascript engine... it also captures the google aesthetic quite well...

those aren't enough to make me switch browsers however... i enjoy a certain level of security with my current setup and would like at least an equivalent level from any alternative browser but it doesn't seem like i'd be able to get that from chrome...

chrome implements two of the three preventative paradigms i've written about before... specifically it implements blacklisting of sites (both sites known to host malware and sites known to be phishing pages) and it implements sandboxing... what it doesn't seem to implement (at least the comic made no mention of it and i saw no sign when i tested it out) is whitelisting...

there are a couple of reasons why whitelisting may have been left out of the mix... the most simplistic of which being they simply weren't familiar with the concept - indeed, website blacklists are in most modern browsers now so they're well known, and there was a mini boom of browser sandboxing tools (enough that google actually acquired one called greenborder last year) so they should be on google's radar too... as far as whitelisting active web content goes, however, there aren't a lot of players - noscript stands out as the only one i can think of (other than IE's trusted zone which almost no one uses because it's not user friendly)...

if we assume google was familiar with whitelisting active web content in general and noscript in particular then another possible reason for it's exclusion emerges - when you look at the frequency of noscript updates (updates that are more than just a new list as you'd get with a blacklist update, updates to the codebase itself) you come away with the impression that technology like noscript is far better off as a plugin than built into the browser... i don't think anyone wants to update their entire browser that often...

finally, a thought that formed while commenting on michael farnum's blog - there seems to be a fundamental philosophical conflict between the default-deny paradigm that whitelists represent and organic growth of application ecosystems... the way web content is developed can be considered to be the very embodiment of organic growth and google makes it pretty clear that they want to help that along, not get in it's way, so it could very well be that whitelisting simply doesn't fit in their security vision...

it's a rather important part of mine, however, so at the very least i won't be switching to chrome until someone makes a noscript-like plugin for it... things won't be all sunshine and lollipops when that happens, though... as i mentioned earlier, the browser is supposed to have sandboxing built in and on the surface that sounds great... unfortunately they haven't figured out how to sandbox plugins... this seems like a pretty big deal to me because flash is a plugin and shockwave is a plugin and quicktime is a plugin, etc... the very active content that isn't being controlled by way of a whitelist is apparently not being contained by their sandboxing technique either... this seems a little backwards because i'm fairly sure that back in the days when greenborder was still around if you ran your browser in that sandbox the plugins stayed in the sandbox too... no worries, we'll just run chrome inside another sandbox like sandboxie - right? try it and you too may be greeted with the "sad tab"...

i've no idea why (i'm no sandboxie power-user) but all pages lead to sad inside a second sandbox and the helpful reload advice sometimes leads to the frozen tab (and boy does he look cold)...
from the looks of things in process explorer, each tab process runs in a sandboxed process with the unsandboxed browser process as the parent but when the browser process is sandboxed it doesn't appear to be able to create it's own sandboxed children (even though a sandboxed firefox can launch vlc in the sandbox without trouble)...

so there's no whitelist and not only is the built in sandboxing insufficient, it appears to kill the option of using a 3rd party sandbox to make up for it's deficiencies... it's pretty, don't get me wrong, i like the look of it - i also like the idea of faster javascript, but i get more security with my current browser setup and when legitimate sites like yahoo mail or cnn are sometimes found to be serving malicious content that security becomes pretty important...

look who's drinking the whitelist koolaid now

from a recent blackhat-related post on symantec's blog:

Symantec has been stressing for quite some time that we are on the cusp of a critical inflection point where the number of unique malicious code instances is surpassing the number of legitimate code instances.

the inflection point (shouldn't that really be an intersection of two curves?) will not and can not be reached... symantec is ignoring the figures provided by bit9 whose core business is application whitelists (so when they say good software is growing at a rate that is greater than what anyone says malware is growing at, despite the fact that it's in their interests to suggest the opposite, you better believe they know what the heck they're talking about)...

symantec is also ignoring the kind of basic logic i used 2 years ago when i said (without the benefit of figures) that good software outnumbers malware and grows faster than malware, and that i described in detail more recently: basically that malware writers are a small subset of the set of all programmers and there's no realistic way for a small group to outproduce a large group...

this reminds me of an earlier symantec gaffe wherein john thompson claimed the virus problem was solved... sometimes i wonder if symantec works on the philosophy of not letting the facts get in the way of good marketing...

if i have a whitelist, do i still need AV?

on reading this dark reading article about a texas bank dumping AV in favour of application whitelisting technology i was reminded of an email conversation i had with a reader who was dealing with almost the exact same issue only days earlier... i've come to realize this is a question more and more people are going to be wrestling with as time goes on so instead of expecting them to contact me privately i'm going to answer the question of whether you need AV software if you have a whitelist here... the glib answer is no you don't need it...

of course that answer continues with: you don't need the whitelist either, or your computer for that matter - people survived perfectly fine before any of that stuff existed...

clearly, the glib answer isn't all that useful...

the real answer is that i can't decide for anyone whether they need AV... in practice security has a lot to do with making trade-offs and which trade-off is right for any particular person or organization is best decided by those who would have to live with the consequences of that decision... what i can do, however, is point out weaknesses in both individual technologies and describe some of the benefits of using them together...

it's no secret that known-malware scanners are ill-suited to detection of new/unknown malware, updates can be a hassle for large organizations, and the ongoing subscription fees have in the past seemed like a necessary evil but are increasingly seeming less necessary as application whitelisting works it's way into the mainstream...

of course, as we know from figures provided by bit9, the set of good software is larger and growing faster than the set of malware so a vendor-supplied whitelist will almost certainly be worse from an update point of view (and maybe subscription-wise too)... the customer-editable whitelist is much more palatable in that regard because you only put on it those things you actually need in your production environment... coming up with the initial whitelist (not to mention modifying it if/when the needs of that environment change or when software needs updating) puts the customer in the position of having to decide what's safe or not... certainly one should only trust software from known, reputable sources but those sources aren't perfect (even microsoft has accidentally distributed malware in the past) so the first benefit of continuing to use known-malware scanner even though you've chosen to use a whitelist is that you can check the software you intend to whitelist (as whitelist vendors often do for whitelists they provide)... this is an example of the axiom "trust but verify"...

that alone may not seem like it's enough to warrant keeping the desktop av, however, so consider this: just as known-malware scanners don't recognize everything that's malware, application whitelist software doesn't recognize everything that's a program... will the whitelist software block office macros if the office binaries are on the whitelist? will it block batch, perl, kixstart, etc. scripts if their respective interpreter is on the whitelist? will it block javascript from the myriad of ways it can be launched on the system? as an example, i use the application launch control functionality of sunbelt personal firewall as a whitelist and i discovered quite by accident recently that it does not block individual batch files... a known-malware scanner would detect known malware in a batch file, however, and in an office macro, etc... that's a second benefit of keeping known-malware scanners around in a whitelist deployment, and it's one that applies even at the desktop level...

that's not all though... there's also the issue of exploit code that exploits vulnerabilities in whitelisted applications... if the exploit needs to launch additional applications that aren't on the whitelist then the whitelisting software will have interfered with and potentially blocked the exploit, but what if all the applications it needs are on the whitelist? the whitelisting software would be helpless to stop it but a known-malware scanner might still have at least some chance to do so...

known-malware scanners are weak against that which is novel while application whitelists (assuming no malware gets whitelisted) are weak against that which is exotic... together they're only weak against that which is both novel and exotic... this is the essence of what defense in depth means when it comes to the anti-malware world - not using multiple different scanners but rather using multiple and entirely different types of technology so that the second (or third, or fourth, etc) line of defense can stop at least some of what gets through the cracks in the previous line(s) of defense... it's still up to the people affected to decide whether the benefits of a multi-layered strategy warrant the cost but they should definitely consider it as no technology is an island, perfect unto itself...

debunking the mythology of whitelist practicality

while i don't normally listen to podcasts, it does occasionally happen and the risky business podcast episode 66 mentioned on the tenable security blog was one of those times... one of the topics discussed was the practicality of whitelists over blacklists and it amazed me (again) that people actually think this way...

why, when the number of developers making good software far outnumbers those making bad software, do people insist on believing there's more bad software than good and it's easier for vendors to keep track of good software than it is to keep track of bad software...

it's a pretty popular belief these days that it's not practical to keep track of all bad software anymore and vendors should be keeping track of the good software instead because that's somehow more practical but that belief starts to look a little ridiculous when you start considering the origins of the good and bad software in the world... just like most people in the world are actually good people (police states would be a necessity otherwise), most programmers are good people too so they're not writing malware... if most of the programmers in the world are writing good software rather than malware then it stands to reason that the production of good software out-paces the production of malware and since it has always been this way it should also outnumber malware...

as such, good software far outnumbers malicious software and is produced at a faster pace than malicious software... however big the set of malicious software seems and however fast it seems to be growing you need to ask yourself how much more aware you are of those stats for malware than for good software (a lot less attention is paid to those figures for good software)... i've mentioned before (and i'll probably mention again) that bit9 actually has some figures related to both the total number and rate of production of good software and it's shocking the degree to which it dwarfs those same measures for malicious software... billions of good programs while there were still less than a million malicious ones, and millions more good programs produced each day while malicious software is still in the range of thousands for the same period...

for the average person this may not seem intuitive; indeed, how could microsoft alone produce 500,000 new files each day - they certainly don't have that many products... the reason for the discrepancy is at least 3-fold... 1) the average person doesn't understand how many different things actually qualify as programs and would need to be kept track of if vendors were to supply whitelists, 2) the average person doesn't realize how many programs go into a single product, and 3) the average person doesn't actually have any idea how many products a company like microsoft actually produces because microsoft produces software for such disparate sets of people... you think ms word is just one program? it's not, it's many different programs that inter-operate to give you the functionality and user experience you're used to... if it were a single program there would be little or no need to install it, you could just run it as a stand alone application... the same holds for excel, and powerpoint, and outlook, and so on and so forth... do you think the hundreds (if not thousands) of megabytes that windows takes up is all because of data? what data does an operating system need? it's mostly programs...

a common refrain these days is that blacklisting just isn't working, but the problem with common notions is that they're often over simplified... blacklisting just isn't working well enough all on it's own... it is a challenge to keep up with the malware production rate so just imagine how much more of a challenge it is to keep up with the good software production rate... sure whitelisting companies like bit9 seem to be able to do it but you wanna know how? by using the same blacklists people think are failing in order to determine what's safe to put on their whitelist... it shouldn't take a rocket scientist to figure out that such a whitelist will be no more accurate than the blacklist it's based on - anything the blacklist misses will get onto the whitelist and then what will you do?

what is a whitelist?

in contrast to the blacklist, a whitelist is a list of known good things that we don't need to avoid, block, or weed out... a whitelist is generally used in situations where nothing is allowed except those things on the whitelist... this is sometimes referred to as 'default deny'...

a classical real world example of a whitelist is the guest list for an exclusive social function (where you don't get in unless you're on the list)... further examples include the list of things you're allowed to put in your recycling bin, the list of foods and drugs approved by the FDA, or the set of people you'd trust with a secret...

in the anti-malware context the most well known example (to average users) of a whitelist is the list of applications allowed by a software firewall to connect to the internet... you can also have a list of applications allowed to execute (or perform any other function), a list of websites allowed to execute scripts in your browser, a list of email senders allowed past your spam filter, etc...

back to index

look who's talking about whitelists now

thanks to an email from james manning i got to see a company called signacert congratulating themselves for being part of the future of security technology...

you see, signacert produces what could be classified as a whitelist type of technology and symantec's canadian VP and GM, michael murphy, was quoted in the media as saying that whitelisting is the future of security technology...

now before i go further i'll make an obligatory disclaimer (because people have gotten the wrong idea in the past) that i am not anti-whitelist, i use whitelisting techniques, i think they can be a worthy addition to a security strategy, but unlike the hypesters i don't sweep their limitations under the carpet...

when a representative from a company as well known and respected as symantec says the type of technology your company happens to produce is the future of security, i suppose it's only natural to want to congratulate yourselves for being on the vanguard - but don't be so quick to pat yourselves on the back that you choose to highlight the words of someone saying foolish things as you'll only wind up looking foolish yourselves...

you see, michael murphy made a grievous error in his representation of scale leading to media statements like this:

The number of malicious software attacks, including viruses, Trojans, worms and spam, is rising exponentially, dwarfing the number of new benevolent programs being developed, making it increasingly difficult for security firms to keep up.

and this:

With more than 600,000 attacks catalogued – 212,000 of them added since January of this year – “we’re approaching a tipping point,” where there just won’t be room in antivirus databases for all of them, Murphy said. But legitimate applications are about the same in number as they were when only about 15,000 attacks had been documented.

that the signacert blogger wyatt compounded by characterizing the blacklist problem as infinite and the whitelist problem as finite... you cannot favourably compare the scale of the set of all known good programs to that of the set of all known bad programs unless your only intention is to say 'my database is bigger'... the set of good programs is orders of magnitude larger and growing faster than the set of bad programs, a fact that researchers from at least one whitelist vendor apparently concede...

if you're going to use the argument of scale against traditional blacklists then you cannot present a centralized whitelist as a viable alternative... the only conventional whitelist whose scale is more manageable than traditional blacklists is the one where the user him/herself decides what goes on the list (with all the potential for wrong decisions and the security implications thereof)... with whitelists you can have a manageable scale OR accuracy enough to protect users from their own bad decisions, but you can't have both...

this is something i would kinda hope the folks at signacert would already know, and i definitely expected the folks at symantec would know this - but the again, considering their CEO made the ridiculous claim that the problem of worms and viruses was solved, perhaps i should have known better to expect that from them... that or i should just know better than to listen to people in non-technical positions talking about technical things...

file infecting viruses vs digital signatures

vesselin's comments to my previous article inspired me to consider actual attack scenarios rather than just weaknesses in a proposed system so i've turned the title of this entry around to indicate more focus on the threats rather than the vulnerabilities...

in one of the responses to the comments i posited a scenario where a malicious entity compromises a legitimate software vendor and infects their software in such a way that they distribute infected programs with valid digital signatures and which can in turn sign executables they infect... today nishad herath posted a similar scenario over at the mcafee avert blog so at least i'm not the only one who thought of this possibility...

but you know what, that's actually a rather complicated scenario so i got to thinking maybe there's a simpler one... then it dawned on me; the premise for this protective technique is to manage the integrity of files and the assumption is that you can't infect files without changing them and thus affecting their integrity... it turns out that this assumption is wrong - certain types of companion viruses can infect a host program without modifying it at all... so if a malicious entity were to get a certificate they could easily sign their companion virus with it and so long as no one figured out the entity was signing malicious code their certificate would never be revoked and the virus could spread unhindered... and in joanna's world where digital signatures replace all the tricks that are used to detect the presence of viruses there would be nothing to alert the general public that the code was malicious and the certificate should be revoked...

ouch, that seems pretty damning, doesn't it... but you know what, companion viruses were always pretty obscure... it wasn't a particularly popular strategy in part because the extra files gave it away to those who were looking for extra files (oh, another one of those nasty virus detection tricks joanna thinks we can do without)... ok, so then how about a virus that inserts the host program into a copy of itself, rather than itself into the host program (the so-called amoeba infection technique) and then signs this new copy with the aforementioned maliciously obtained certificate? once again, a digital signature based whitelist isn't going to stop this from happening...

now that takes care of one of the aspects that kept companion viruses obscure but it doesn't really improve on the obscurity itself as this technique is even more obscure that companion infection... if you've followed me to this stage perhaps something else has dawned on you - if a virus can sign a copy of itself with a host program inside of it, why shouldn't it be able to sign a host program that it had inserted a copy of itself into using a completely conventional infection technique and the malicious entity's certificate? the answer is there is no reason it can't...

so it would seem that a digital signature based whitelist where vendors sign their own programs (effectively vouching for the safety of their own code) wouldn't really prevent file infecting viruses at all if that were the only thing the world were using... you still need all sorts of tricks to figure out when a vendor's certificate can't be trusted anymore, which points back to a fundamental problem with this kind of self-signing system - it correlates identity (which is the only thing a certificate authority can test) with trustworthiness in spite of the fact that they don't actually have anything to do with each other... just because the vendor's front man is who he says he is and hasn't done anything bad in the past (that anyone knows of) doesn't mean the vendor itself isn't a malicious entity... currently, standard certificates (like the ones used for websites) have become so easy for anyone to get that they've become meaningless and this lead to the creation of extended validation certificates which simply involves more in-depth investigation of the entity and which in turn has no bearing on what the entity will do after getting the certificate... i can see no way for a digital signature system for code to work any different than the one used for websites so the same problem will apply; and then even if we somehow figure out that the entity cannot be trusted, their virus(es) will continue to spread until a revocation is issued for their certificate and that information trickls down to all the affected systems...

trusting the vendor (or whatever else you want to call the software provider) to attest to the trustworthiness of their own software just seems far too naive from a security standpoint, which is why i originally didn't even consider it to be the model joanna had been talking about... a system where independent reviewers checked programs for malicious code before signing them (essentially certifying programs rather than program providers) seemed to be a safer solution, though it's got the same scaling problems that conventional centrally managed whitelists have... a system that certifies programs rather than program providers would be less vulnerable to the scenarios mentioned here (i think only a variation on the first one should be able to allow viruses to still spread) but either way, both options still allow viruses to operate if used on their own... at best (and by now this should sound familiar) digital signature based whitelists should be something we use with the more conventional tricks we're used to, not instead of them as joanna rutkowska would like you to believe...

digital signatures vs file infecting viruses

so joanna rutkowska actually talks about things other than so-called rootkits... this time (i won't link to the article for known reasons) it's file infecting viruses...

from the article:

But could the industry have solved the problem of file infectors in an elegant, definite way? The answer is yes and we all know the solution – digital signatures for executable files. Right now, most of the executables (but unfortunately still not all) on the laptop I’m writing this text on are digitally signed. This includes programs from Microsoft, Adobe, Mozilla and even some open source ones like e.g. True Crypt.

With digital signatures we can "detect" any kind of executable modifications, starting form the simplest and ending with those most complex, metamorphic EPO infectors as presented e.g. by Z0mbie. All we need to do (or more precisely the OS needs to do) is to verify the signature of an executable before executing it.

I hear all the counter arguments: that many programs out there are still not digitally signed, that users are too stupid to decide which certificates to trust, that sometimes the bad guys might be able to obtain a legitimate certificate, etc...

But all those minor problems can be solved and probably will eventually be solved in the coming years. Moreover, solving all those problems will probably cost much less then all the research on file infectors cost over the last 20 year. But that also means no money for the A/V vendors.

first things first - this is essentially a whitelist technique (with the added bonus that the cryptographic component allows the proof of whitelist membership to be shipped with the file instead of requiring a lookup in a very big list) with all associated fundamental problems... think the problem of signing all good programs is small and will probably be solved? maybe for suitably large values of small... if you're going to focus on identifying good files instead of bad ones you have to keep in mind that the good files outnumber the bad by orders of magnitude and grows at an even faster rate... conceptually signing all good programs is simple, but in practice it's very, very hard...

but let's assume we do solve that problem... so if the file isn't signed then it doesn't run and if the file's signature is invalid then it doesn't run... the presence of a valid signature is assumed to mean that the file is a) not bad and b) hasn't had anything bad put into it after signing, but is that a valid assumption? given that mobile spyware can get digitally signed by symbian, i think not, at least not for the first part of the assumption... currently digital signatures like the ones joanna holds up as examples are meant to prove authenticity, not safety... putting the onus on the signatories to determine whether the code they're signing is safe doesn't solve any malware problem, it just offloads it onto the signatory... this is also not a small problem: distinguishing good from bad is and always has been the problem and offloading it onto someone else doesn't make it any easier to solve...

the second part of the assumption, that verified signature implies nothing bad has been put into the file, may well be true, assuming that the verification system itself hasn't been compromised... the digital signature proves authenticity and one of the prerequisites for authenticity is integrity and that's really the underlying ingredient here - managing system integrity... any application whitelist worth it's salt already keeps track of the integrity of the executables on the whitelist, otherwise it would be trivial to fool it by simply replacing a whitelisted application with a piece of malware with the same filename... but as yisreal radai showed in his paper "integrity checking for anti-viral purposes: theory and practice" (sorry, no suitable non-vx links at this time), systems that detect changes to the integrity of files are subject to attack and one based on digital signatures is no different... the signing key could be stolen (there's been malware designed to steal cryptographic keys in the past) and then generating valid signatures for infected files would be trivial, the key used to verify the signatures could be altered (either on disk or dynamically in memory) by a malicious process that has already been signed, or if the system allows adding new keys then one could be added maliciously that would allow the files to be modified (infected) and then resigned with the new key to trick the system into thinking the file's integrity is intact... in fact, taking a cue from the developers of stealth technology under windows, one could simply change the result returned by the signature verification function... in order to be immune from attack, an integrity checking system has to be offline and out of reach of the attacker, and that's not compatible with a system that checks integrity in real-time to prevent modified files from running...

of course there are other problems too... it's not just deciding what to sign, ensuring the signatures are themselves trustworthy, and finding the resources to sign every good program in existence... there's also the classic whitelist problem of deciding what to do in an environment where programs are being created (or even what's a program in the first place)... are we going to digitally sign word documents? yes? ok, and will that stop macro virus infection? no of course not... there are plenty of macro viruses that infect a document when the document is saved - a point at which a new digital signature would have to be created anyways... then when the person we send the document to opens it the virus runs and then proceeds to infect documents that person creates or modifies (and then signs) and so on and so on...

again, from the article:

So, do I want to say that all those years of A/V research on detecting file infections was a waste time? I’m afraid that is exactly what I want to say here. This is an example of how the security industry took a wrong path, the path that never could lead to an effective and elegant solution. This is an example of how people decided to employ tricks, instead looking for generic, simple and robust solutions.

unfortunately a digital signature based whitelist is no elegant solution either... whitelisting for anti-viral purposes dates back at least as far as thunderbyte anti-virus and there have always been ways to manually check the integrity of transfered files to make sure they haven't been altered from what original vendor was distributing by using crc's, hashes, and even digital signatures... a digital signature based whitelist makes certain aspects of usage a little more convenient, but it doesn't mitigate the inherent problems of a whitelist...

joanna may have wanted to use this to demonstrate the way security solutions ought to be in an ideal world, but the world is not ideal, and the virus problem as well as the many varied ways of addressing it are not as simple as she portrays them... thus her example of security gone wrong has no legs... in the real world there is a counter-measure for every protective measure, and elegance (subjective as it is) cannot be the basis upon which the measures we take are judged...

the three preventative paradigms

something i've had circling around in my head for a while now is a fundamental division between malware prevention techniques... i'm moderately certain i've missed something (because three just comes up way too often in security) but it seems to me that everything falls into one (or more) of three broad categories: blacklisting, whitelisting, and sandboxing...

i know, right now you're probably saying "kurt! you missed a whole bunch of stuff - what about heuristics? what about behavioural techniques?"... well, lets look at that - what does behaviour-based malware detection do anyways? it monitors behaviours, sure, but how does it decide something is bad? what's going on is that it's actually comparing the behaviours (or combinations thereof) to a list of known bad behaviours (or behaviour combinations) which means it's a type of behavioural blacklist... likewise, heuristics compares properties (like the presence of certain familiar routines) of the program being scanned to a list of properties known to be used in bad programs and so also represents a type of blacklist... the blacklist technique is not the exclusive domain of signature scanning... anything that tries to identify something as bad (basically anything that tries to algorithmically answer the question "is this bad?") must do so by comparing it or some aspect of it to a list of known bad things of a similar type - and that makes it a blacklist...

"but kurt," you say, "that's not the only kind of behavioural technique out there. what about ones where you define what behaviour different programs are allowed to perform such as provided by various HIPS products?"... well, you'd be right, that behavioural technique is not a blacklist... besides being a process-centric access control system, it is more generally a behavioural whitelist... just as the blacklist technique is not exclusive to signature-based virus scanning, the whitelist technique is not so narrowly defined as to only specify application launch whitelists and/or the preferred paradigm for deploying firewalls... if it tries to block everything that isn't good/allowed/authorized (rather than everything that is bad/not allowed/unauthorized) then it must first be able to answer the question "is this good/allowed/authorized?" and to do that it must have a list of known good/allowed/authorized things - and that is a whitelist...

so if it answers the "is it bad?" question it's a blacklist and if it answers the "is it good?" question it's a whitelist - what's left? you might think it's some combination of the two but in fact it's not answering any question at all... the truth is our ability to answer either of those questions is limited so we need to take care of the case where we can't answer either of them and that's what a sandbox does... rather than blocking things outright based on knowledge of what's good or what's bad, sandboxing prevents malware intrusion to the host system by misdirection... the software which may or may not be malware is given a sandboxed environment to work in rather than the host environment and barring any ability to escape sandboxes, what happens in the sandbox (good or bad) stays in the sandbox... it doesn't necessarily prevent extrusion (leaking) of sensitive data you enter into applications running in the sandbox, mind you, and in that sense is a lesser form of prevention - but preventing malware from affecting the host system without any knowledge of or ability to decide on what's good or bad is no small feat...

if we could just assume everything that a blacklist doesn't alert on was good then life would be simple, but unfortunately that's not the case... likewise, assuming everything that isn't on a whitelist must be bad isn't very useful either (at least not unless you're dealing with very restrictive environments and even then there are complications)... once again, these three approaches are complementary and are best used together...

more on whitelisting

or perhaps moron whitelisting... yes dave, i'm taking the bait with the emperor's robin bloor's new clothes article about the decline of anti-virus and the rise of whitelisting... and it's pretty good bait too, since i wrote the rise of whitelisting (anything look familiar?) over a year ago in response to something else robin wrote when his misguided anti-virus-is-dead campaign was still new (a day old judging by the posting dates)...

i haven't really seen much new material that i didn't cover myself in that first response - exotic execution, accuracy of local whitelist management, and scalability of global whitelist management are all outstanding problems with whitelisting... finding out that the whitelist vendors themselves admit to the unmanageable scope of their own efforts is one of the few new things that have come up since then...

robin doesn't address any of this, of course, and like the emperor's new clothes there really isn't anything there in his new article... 2 whitelist companies merged and became bigger than either was before - big woop...

the only interesting things were the comments on the register's mirror of the article... vesselin bontchev hit the nail on the head several times (and i'd expect nothing less, though i wouldn't have expected vess to be first to post on the register - ugh), but what interested me most was the suggestion that robin bloor's 'research' is funded by the whitelist industry...

clearly this would be some segment of the whitelist industry that is misguided enough to think that anti-virus companies are actually their competitors... it's apples and oranges though, av companies won't be competitors until they start offering whitelist technology of their own... what's so misguided about this, though, is that if they actually manage to take av's place on peoples' desktops they're ultimately going to wind up also taking av's place in peoples' cross-hairs... if they displace anti-virus then people will necessarily become just as disenfranchised with whitelisting as they are with anti-virus because whitelisting has failings too...

in the comments robin does admit that whitelisting won't stand on it's own and that additional technologies will be needed to complement it but weasels out of saying what... i suspect intuitively he knows the answer: at the highest, most abstract level, what complements a whitelist? that's right, a blacklist... though he expressly derides the idea as "positioning" in his article and says that you should nevermind it, the fact is that known malware scanning and application whitelisting are natural companions...

i want to call robin bloor a troll, i really do, but if he's being funded by whitelisting companies then what he really is is a shill... either way, i'm done with him - when my arguments (and most other peoples' arguments) now are the same ones i posted if march of '06 there really is little point in continuing with this... besides, considering the uptick i get in hits based on searches involving the term whitelist when he posts more nonsense, i'm pretty sure the counter-arguments are being heard without additional effort on my part so i can put that you are being trolled feeling to rest...

the slow death of someone's credibility

robin bloor doesn't show up on my radar very often, but when he does it always seems to be about how anti-virus is dead, dying, or doomed in some way... this time it's about the slow death of anti-virus technology...

dave lewis thought it worth pointing to (thus leading to the blip on my radar) and the folks over on the authentium blog went against their better instincts and actually responded to it...

it's a good response, too, and it touches on a point i've also made about whitelisting - specifically that the numbers of good programs (ie. those that would be put on the vendor supplied whitelist) far exceed those of malware... why this is interesting is because one of the main arguments against anti-virus technology is a fundamental disdain for enumerating bad things on the premise of it being too big of a problem... clearly, if enumerating good things is several orders of magnitude harder than enumerating bad things then this particular argument is garbage... it's nice to see that a whitelist vendor is owning up to the enumeration cost, even if some whitelist proponents are unwilling... to the unwilling i would say imagine if the TSA used a whitelist instead of a blacklist - do you think telling most people they can't fly because they aren't on the fly list would work better than telling a few people they can't fly because they are on the no-fly list?...

this time around mr. bloor wants us to believe that, because whitelisting is gaining traction in the market, his prognostications about whitelisting replacing blacklisting are gradually coming true... seemingly choosing not to consider the possibility that the trends he's noticed are nothing more than the maturation of the whitelisting market, and unperturbed by history's numerous examples of the av industry adding technologies to their portfolios rather than replacing the old with the new, mr. bloor's arguments seem rather ridiculous...

but then again, they're coming from the same guy who thinks traditional polymorphism and server-side polymorphism are comparable - that because traditional polymorphism (where the transformation function responsible for the polymorphism is carried with the self-replicating malware and therefore open to attack by the av'ers) has been around for 16 years that the av industry should have developed something capable of dealing with the newly emerged server-side polymorphism (where the transformation function isn't carried by the malware and thus isn't generally open to attack) by now...

so should anyone take him seriously when he says whitelisting is better than av and that it's going to replace av? no, because whitelists are not going to replace blacklists, whitelists aren't better than blacklists, they're just different from blacklists... whitelists don't have the same weaknesses blacklists do just as blacklists don't have the same weaknesses that whitelists do... the notion that we would or should use only one type of technology to protect ourselves from malware is antiquated and fundamentally broken - there is no silver bullet, no panacea, and if you don't employ a multi-layered strategy (aka defense in depth) then you're just setting yourself up for unnecessary failure... i have to wonder, when av technology is still here 10 years from now, will robin bloor be eating crow or will he still be forecasting av's death like some inverted version of monty python's parrot skit...

anti-virus is not a faulty burglar alarm

wow, what a great analogy robin bloor makes here... too bad it's his reasoning that is faulty...

one of my favourite turns of phrase lately is mismatched expectations - robin bloor is quite clearly suffering from mismatched expectation by likening anti-virus to a faulty burglar alarm... anti-virus is nothing like a burglar alarm, faulty or otherwise, nor is the problem it is trying to solve amenable to a burglar alarm type of approach...

burglar alarms are pretty simple things - you have one or more sensors that detect basic, easily quantifiable environmental conditions (broken window, open door, motion, etc) and an alarm goes off when the sensor is triggered... this is pretty dumb, all things considered, but it works well enough when the thing you're trying to detect can be broken down to such simple events and even better when the home owner can easily decide whether something is a false alarm...

the malware problem, by comparison, cannot be broken down into simple elements quite so easily and end users are largely incapable of deciding whether an alarm from a malware detector is false or not... this is why behavioural detection techniques (which have been around for over a decade) are still not receiving the same kind of mainstream attention that known-virus scanning receives... instead of going the burglar alarm route, anti-virus incorporates a considerable amount of knowledge about the viruses (now more generally, malware) that the vendor has seen in order to minimize false alarms... anti-virus still has false alarms, of course, but just imagine how bad it would be if av were made to be as dumb as a burglar alarm... if we're going to stick to crime-related analogies, anti-virus is really much more like the criminal databases that have proven so useful in the past to keep known felons out of places they're not supposed to go or out of job positions they shouldn't have... not that those databases are perfect, but they sure do help...

of course, bad analogies are not the only thing robin has up his sleeve in that article... he spreads some clever FUD about the malware pandemic using carefully selected figures from a microsoft study i wrote about once before... yes, the malicious software removal tool removed malware from 5.7 million computers, but what robin fails to tell you is that it scanned over 270 million computers... that gives a malware penetration just 2.1% - hardly a pandemic...

all this is to build up to his conclusion that application whitelisting is a superior technology that should be used in place of anti-virus... maybe it is superior, maybe it isn't, it depends on things i've mentioned elsewhere, specifically whether the user can accurately decide what is safe to add to the whitelist and whether the whitelist can cover enough of the various types of program execution (it's not just *.exe's out there)... should whitelisting be used in place of blacklisting (anti-virus)? no, in reality blacklists and whitelists complement each other, they partially mitigate each others weaknesses, so they really ought to be used together...

and just as a point of correction - contrary to mr. bloor's assertion, application whitelisting is not relatively new... the basic idea dates back at least a decade as an anti-virus (gasp!) suite known as thunderbyte anti-virus included a rudimentary form of whitelisting in it's tbcheck module... tbav was a fairly well known product in it's day and there was plenty of opportunity for whitelisting to become popular, but it didn't... others have languished in obscurity too... anti-virus seems to have remained the most popular in part because it required the least amount of knowledge and/or thinking from the end user - and when it comes to malware, that can actually be a very good thing...

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...

the rise of whitelisting

application whitelisting, the practice of keeping a list of known good applications (a whitelist, as opposed to a blacklist) and only allowing those applications to run, is not a new idea... it's a good idea certainly, but not new... nick fitzgerald, for example, has been calling for the development and deployment of just this type of technology for years now... i myself utilize the application launch control functionality (a sort of whitelist) in kerio personal firewall (which is more interesting to me than the actual firewall part)...

today, however, there was a post on the nod32 news blog about whitelisting that i think underlines the need to delve into the strengths and weaknesses of the technology...

at the most fundamental level an application whitelist needs to know 2 things, what sorts of things are programs and which of them are known to be good...

determining what is a program and what isn't is not as simple as it sounds - in fact it's an intractable problem (unless someone solved the halting problem without telling me)... that's not to say we can't make that determination accurately most of the time... basically we're limited to detecting known program types - new types of script programs and that sort of thing are always going to exist and always going to be left out because they're too new... at any rate, this level of detection is always hard-coded into the whitelist system by the developers - there's no real way to add new program type detection on-the-fly on the end user's machine...

where things really get interesting is when we're trying to identify the known good programs... there are 2 main paradigms we can follow: either the 'goodness' is determined by the end user and is specific to his/her machine only, or the 'goodness' is determined by some central body somewhere that decides what's good for everyone... it's also possible to combine these two but let's look at them individually first...

in decentralized whitelist management (where the end user decides what's good) the list of known good things is relatively small and can be updated whenever the user needs to but there is a serious problem trying to enable end users to accurately determine the trustworthiness of new software... most people just don't have the expertise or inclination to perform the necessary research to find out if something should be allowed to run on their machine... frankly, if they were any good at making those kinds of decisions, email worms (and just about every other type of malware out there) would never have become as big a problem as it is today...

in centralized whitelist management (where a central body decides what's good) it's possible to have lots of expertise on hand to determine whether a specified program is good or not but the list of known good things needs to be huge in order to cover everything that everyone might use... one of the arguments against known virus scanning and in favour of whitelisting is that keeping track of all the known bad things (essentially a known virus scanner implements a blacklist) is that the number of known bad things is very large and ever-growing, but a centralized whitelist has this same problem in spades as determining if something is good is just as hard as determining if something is bad, there are far more good programs out there than there are bad ones, and the list grows even faster... in addition, the central organization will undoubtedly have finite resources with which to work so adding updated programs (a number of programs out there do tend to have regular security updates) to the global whitelist may not happen in as timely a fashion as we might like... finally, it puts the central organization in a position where they could exercise undue influence over which legitimate applications get to run on end users machines (presence on the whitelist would effectively be a certification and has many of the same undesirable properties that the system where a certifying authority digitally signs the known good programs so that people would know which ones they could trust)...

combining these two into a hierarchical whitelist management system (where the global whitelist serves to help the end user determine the trustworthiness of programs most of the time) would seem like it would give the best of both worlds but that's not necessarily the case... giving the end user the power to add a program to his/her local whitelist gives him/her the power to make the same mistakes s/he'd be making with a fully decentralized whitelist system - with the understanding that the global whitelist isn't always going to be completely up to date a piece of malware need only advertise itself as the latest security update of some widely deployed program (like part of the operating system, for example) in order to get the user to add it to the local whitelist... also, giving the end user the power to add programs to his/her local whitelist doesn't obviate the need to make the global whitelist as thorough and up-to-date as possible, nor does it make the task any easier or less time-consuming/resource-intensive... further, the absense of a program on the global whitelist could still communicate a lack of trustworthiness to the end users and bias them against a particular legitimate application...

even if you could solve all these problems, it's still possible to make good programs do bad things... and i'm not just talking about buffer overflows and other software exploits, the whitelist can't know that you want Format.com to run sometimes but not others... it can't know that Regedit.com should import the *.reg file with your personal configuration preferences in it but the *.reg file that disables the whitelist on the next reboot and causes the download and execution of some piece of malware... it can't know that your SQL server should run the query that selects all your customer table but not the one that self-replicates all through that same table... it also does nothing to stop malware that exists only in memory, nor malware that executes outside the scope of the operating system (like bootsector malware)

all that said, it should be fairly obvious that if you only let known good programs execute, then the bad programs (known and unknown alike) generally won't be able to run on your system... with a whitelist in place monitoring the attempted launching of applications you'll also get alerted when something you don't know about tries to run... finally, with a relatively small and static set of applications allowed to run, the security of the system is more easily analyzed and modelled...

application whitelisting, like integrity checking/change detection before it, may offer a technically superior security technology in theory, but in practice it is not a panacea... it's not a magical cure-all and it really doesn't eliminate the need for conventional anti-virus/anti-malware scanning... like all anti-malware technology, it is best when used in conjunction with complementary technologies and techniques...