Thursday, April 22, 2010

mcafee's catastrophic false alarm

mcafee recently published a signature update which, when applied, caused their anti-malware software to falsely identify a critical windows component as malware and quarantine it. hilarity did not ensue. boot failure, on the other hand did.

what the hell, mcafee? i thought you folks knew better. this is not the first time a catastrophic false alarm has happened - i don't think it's even the first time it's happened to you. this is a problem that was identified years and years ago and i would have thought that every major AV vendor would have figured out how to avoid this.

i guess i was wrong, so i'll spell it out:
  1. maintain a library of every version of every critical operating system component
  2. before you release a new signature update, use a system with that update applied to scan the aforementioned library of critical operating system components
  3. if there are any alerts, DO NOT RELEASE
this isn't rocket science - it's not even all that computationally expensive because it's just the critical files and just for the OS. sure it would be great if you could do this kind of testing to ensure you don't break a bunch of other things, but preventing the bricking of customer computers should be the bare minimum.

i'm not sure what kind of QA you're doing on your signature updates, but if you're not including this test (or worse if you are and this still happened) then you're doing it wrong.


EDITED 2010/04/22 19:59: it occurred to me after posting the above that there was in fact another way this problem could have been avoided that is perhaps a little more sophisticated.

for years now spam filters have been using whitelisting as a means of avoiding falsely classifying correspondence from important contacts as spam. if mcafee's known malware scanner were outfitted with a small whitelist of critical OS components that must not be false alarmed on under any circumstances then svchost.exe wouldn't have gotten quarantined and mcafee customers would have been saved a great deal of hassle.

this is a perfect example of how blacklists and whitelists can complement each other. i've been saying for a couple years that blacklists, whitelists, and sandboxing were complementary technologies and i've felt that anti-malware products would be even better if they incorporated all 3 of those preventative paradigms. to date the only vendor i'm aware of who actually does that is kaspersky (apparently they introduced sandboxing into their internet security suite this year), but as i haven't tried the product i can't comment on the efficacy of their execution. i'm also not so sure any of their whitelisting is integrated into their blacklist in the manner described above.

Wednesday, April 07, 2010

poking holes in trojans

it seems like only days ago when this blog's longest comment thread in recent memory drew to a close after a heated discussion on the definition of trojan and now it seems that not long after both chet wisniewski and david harley posted blog entries featuring that very classification.

not only that but chet's usage of the word as an umbrella term for all non-replicative malware doesn't seem to match david's usage - nor does it agree with my definition (which i imagine probably doesn't exactly match david's either). all of which just goes to show that there really isn't a universally agreed upon definition of trojan. no matter which definition you use there are always some problems with it.

that being said, there are some ideas in chet's post that mirror topics brought up in the aforementioned comment thread and that i think should be brought out front and center.

starting with the low-hanging fruit, let's look chet's example of a trojan that you don't have to execute in order to become a victim of - that being the drive-by download. now i realize that my computer science background has allowed me to develop some rather transcendent notions of what execution means (even going beyond this), but i really don't think one needs to go that far to get the concept that when you open a web page you're executing it's contents. a web page is a container for data and a wide variety of executable content (from javascript to flash to activex to silverlight, etc) and, rather than bog down the user experience with endless prompts to execute this, that, and the other thing, browser developers decided that opening a webpage should result in the execution of whatever executable content it contains. this is something that doesn't get nearly as much attention as it probably should and as a result most people aren't aware of this rather significant detail (otherwise more people would be using noscript) and consequently make bad decisions about how to use the web. i expect that chet himself is all too aware of the executable potential of web content but he's not passing that knowledge on to the reader when he tells them that drive-by downloads don't require any user interaction. the user opened the page in the first place (or opened another page that lead to the drive-by download page being opened) so they did interact in the sense of executing something. clicking a link in your web browser isn't that much different than clicking an *.exe in your file browser, and if more people understood that they might be more careful online.

more generally, the notion that something can be a trojan without requiring the user to execute something seems very odd to me. it seems to me that a piece of malware that doesn't need the user to execute it, that doesn't need the victim to let it in past the defenses, simply doesn't bare much similarity to the legendary strategem from which the name trojan horse program is derived.

i realize that analogies shouldn't be carried too far but to say that all malware that doesn't self-replicate (basically everything that's left over once you remove viruses and worms) is a trojan horse makes me wonder why on earth they chose the term trojan horse in the first place. the definition and the name seem to have no obvious connection. perhaps at the time they simply hadn't conceived of any malware that didn't conform to the paradigm used by the ancient greeks, but is that still true today or could i conjure up some malware examples that just don't seem like they should be called trojans at all? for example, when we think about malicious software we often think about that which runs on the victim's computer, but what about malicious software that runs on the attacker's computer? a participatory DoS tool, for example, would certainly seem to belong to the malware set since it's malicious software, and it certainly doesn't belong to the self-replicating set, but can you imagine something whose malicious functions are both known and advertised being called a trojan horse? should we call every implement of war a trojan horse instead of just the actual hollow wooden horses? catapults will henceforth be known as trojan horses, trenches also, swords and guns and chemical weapons, all of it. while we're being absurd let's call everyone bruce in order to avoid confusion. g'day bruce.

how about an example that does execute on the victim's machine? now remember i'm trying to steer clear of anything the victim user would let in past his/her defenses so the question you might be asking yourself (after taking into account just how liberal my concept of execution really is) how on earth such malware would get onto the victim's system? the answer, of course, is that it's planted there by an attacker who has already gained access to the system. back in the early 90's (perhaps even earlier) there was this attack technique whereby an unsecured system would be used to sniff out enough information (generally login credentials) to compromise a more secure system (because users of the unsecured system might on occasion access resources on another system), which in turn would then be used to sniff out information to compromise an even more secure system and so on and so forth until the attacker reached his/her goal. the attacker would use a collection of tools, often including some sort of back door in the form of a modified system binary as well as a password sniffing program, that were at least in the beginning known as toolkits (eventually one of these toolkits got named "rootkit" and the rest, as they say, is history). now i'll admit that the modified system binary that provides a back door does seem to bare at least a passing similarity to what we'd think of as a trojan horse program even if the victim didn't let it in him/herself (it's something that the victim could have easily let through the gates if given the chance), but in this context, rather than baring a similarity to the trojan horse of old, this bares more similarity to converting an existing agent into a double-agent. additionally a password sniffer in and of itself doesn't necessarily strike me as being particularly trojan-like. it's a packet sniffer that filters what it captures. it's not even clear that it's malicious until you take the context of it's use into account.

that sort of context sensitivity is often cited as a property of the trojan set but i believe it is a property of the malware set (of which the trojan set is a proper subset). in fact i think the trojan set inherits that property from the malware set. i also think that at the end of the day it's that property which makes the question of how to define such a set pointless. the term "trojan horse program" should probably go down in infamy as one of the anti-malware community's great failures because in it's unqualified form it has been one of the most singularly unhelpful classifications. back when there were only 3 major subclassifications for malware (virus, worm, and trojan, as chet mentioned in his post) we had quite a successful anti-virus industry that handily took care of viruses and worms, but not really trojans. both viruses and worms have functional definitions and trojans (whether you consider them the complement of the self-replicative set within the malware set or something more specific) do not. it wasn't until we started carving out functionally defined subsets of the trojan set (such as spyware and adware) that we started to actually get a handle on trojans. problems need to be well-defined before we can hope to address them.

so maybe we should all just forget about trojan as an unqualified term and only use it when we're talking about things like remote access trojans or downloader trojans. while we're at it, let's make sure we continue to carve out new functionally defined subsets of the malware set when fundamentally new behaviour comes along so that we don't sit around gazing at our navels and lamenting how difficult it is to classify things as belonging to an ill-defined set. we've already had an anti-spyware industry, an anti-trojan industry, an anti-rootkit industry, etc. due to slow response by anti-malware incumbents - we don't need to keep doing that.