eEye and malware creation ethics

wow, i just got done throwing out a mention to the new MBR stealthkit and now i find out it's pedigree...

folks, it's time you go over your malware researchers with a fine-tooth comb because i don't think anybody in the industry really wants to be responsible for another proof of concept getting into the wild...

that is, unless you're eEye digital security, apparently... not only was it their researchers derek soeder and ryan permeh that created bootroot and presented it at blackhat in 2005, but even as i type eEye is hosting that malware on their website right now...

this is absolutely NOT responsible behaviour and the people who were and are responsible for both the stealthkit and the company should be ashamed of themselves for being part of the problem instead of part of the solution... anti-malware researchers and companies should not be creating and distributing malware - this is so fundamentally wrong i'm actually tongue-tied trying to describe how wrong it is... needless to say i won't be touching anything of theirs with a 10 foot barge pole and others might want to consider the same...

*update* - tyler reguly caught or otherwise helped me see a factual error i made... the stealthkit in the wild is not the exact one developed and distributed by eEye but rather is a modified version of it... that doesn't really change much, however, because they still armed the bad guys...

snake oil from eEye digital security

found this eEye digital security press release thanks to the infosec sellout blog... i agree with a lot of what the infosec sellout says about this press release but there's one thing s/he doesn't say, one phrase s/he doesn't use that i think it really needs to be said... in the press release in question, eEye is peddling snake oil...

take a look at this quote:

eEye is combining its own anti-virus dynamic heuristics technology with ‘sandboxing’ technology from leading anti-virus vendor Norman Data Defense to complete Blink Professional 3.0 as a single, small-footprint agent, incorporating multi-layered security methods to protect against both known and unknown vulnerabilities in real-time, thus making it the last security product enterprises and SMBs will need to purchase to stop 100 percent of malware attacks, regardless of signatures or patch updates.

do you see what i see? there's a fairly blatant implication that their technology will stop 100% of malware...

long time readers will probably recall past articles on snake oil and realize that snake oil is something i feel pretty strongly about and that this is a punch i will not pull... least of all in this instance with an example of one of the oldest and best known forms of snake oil in the malware domain...

detecting and/or stopping 100% of viruses (which is a subset of malware) is basically the archetype for anti-malware snake oil... it was the epitome of intellectual dishonesty among the less reputable vendors of the past and a cornerstone of most if not all the anti-malware snake oil to follow... there's no good reason why something like this should have been allowed to slip through the cracks unless eEye doesn't care about the quality of the message it sends out to people - and if that's the case, i would strongly suggest voting with your wallets...

eEye on malware naming

y'know, when you're in a position where you're supposed to be an authority on a subject and you're talking about something seemingly related to that subject, it behooves you to either know what you're talking about or stop talking...

in marc maiffret's case neither of those paths were taken... it's amazing to me that the chief technology officer at eEye would say something like this:

"In the vulnerability world, we have CVEs [Common Vulnerabilities and Exposures] as a way to know that we're all talking about the same vulnerability regardless of what we might have named it in our product. In the anti-virus world, there's not really anything like that."

has he been asleep for the past year or more?* because the CME (common malware enumeration) has been around since october 2005 (actually 2005 this time)...

it's difficult to take anything he says seriously after such an incredible gaffe but it's also difficult to let such clear (and frankly surprising considering his position) false authority syndrome slide...

you see, marc would have us believe that the vendors are fighting over who gets to name what and that because they're making "really good money" that they have no incentive to address the naming confusion and give users what they "are actually asking for"... apparently in marc's experience if you just put your mind to it you should be able to get 20-30 companies who operate independently (necessarily so since they're producing signatures for use with different technologies) to co-ordinate the naming of hundreds of malware samples per day while not compromising their top priority of getting detection capabilities (which necessarily require a name, any name, good or bad, to identify what is detected) to users as fast as possible...

that was sarcasm, of course... you can't co-ordinate malware naming without slowing down the process of getting signatures to customers and thus compromising that top priority - and i'm pretty sure that most people would choose a speedy signature turn-around (which directly aids in prevention) over harmonized naming (which doesn't)... while you're waiting for for those 20-30 companies to figure out if they already have a copy of your to-be-co-ordinated sample and which of their many samples that is, your analysts have already finished their analysis and have created signatures to be pushed out to customers...

what they can do (and the main CME page indicates they have done on occasion) is rename the malware after the fact, either to adopt the name other companies are using or to append the CME identifier to the name... unfortunately, this still requires time and effort to co-ordinate a harmonized name and thus cannot possibly be done for each of the hundreds of samples anti-virus companies process each day - especially when most of those hundred samples are complete flops in the wild (making the work to harmonize their names wasted effort)... even without explicitly renaming their samples, the CME lists the various names associated with particular CME id's and that resolves much of the naming ambiguity end users are likely to encounter...

so next time you see someone attributing the malware naming mess to lack of interest or petty rivalry, take a moment to consider the realities of the situation and ask yourself how or even if those logistical problems can be overcome (without fundamentally changing the anti-malware landscape, since obviously naming wouldn't be a problem if there were magically only one company)...

ADDENDUM: i've been informed by marc maiffret that he was misquoted in the article in question, at least a far there being nothing like the CVE in the malware world (maybe other things too?)... as such, i apologize for characterizing marc as suffering from false authority syndrome (and for being asleep for a year or more) since it's no longer clear that's the case... it seems the article's author, scott m. fulton, may be more responsible for the false picture that article painted... i do stand by my criticism of the notions put forth in that article though - the problems associated with malware naming are not easily overcome, nor trivially attributable to character flaws in the vendors...