of logic and malware

i've been accused of (among other far more odious things) having formal training/education in the area of logical debating. i don't actually have said training, but i do know a thing or two about logic, so when i read ed moyle's post on security curve about the industry's flawed logic as it relates to malcon it didn't take me long to realize how ed's logic (rather than the industry's) had gone pear-shaped.

to quote:

• Major premise:  All conferences that provide details on how to create malware are a “bad idea”
• Minor premise:  Blackhat/Defcon provide details on how to build malware (e.g. the Invisible Things Blue Pill presented at Defcon 2006; stated goal, “creating 100% undetectable malware”)
• Conclusion:  Blackhat/Defcon is a “bad idea”.

i can use a similar pattern to equally questionable results:

• major premise: cats are furry
• minor premise: marmaduke is furry
• conclusion: therefore marmaduke is a cat

this is the sort of logic statement i recall seeing on tests as a child. often they'd be worded in such a way as to be tricky so as to test our ability to judge the validity of a supposed logical argument. in my example the primary problem is the major premise. while it is true, it's not specific enough to be useful; many things other than cats are also furry.

likewise ed's premises have problems. starting with his minor premise, the details about how to make the blue pill were actually not given out. those details were behind a pay-wall rather than being freely handed out at the talk. furthermore, the classification of the blue pill as malware is questionable at best. just because it's a so-called 'rootkit' doesn't mean it's malware - the reason being that current use of the term 'rootkit' has become so twisted (by which i mean anything that hides things gets called a 'rootkit' now) that even anti-malware products got called rootkits. the blue pill was a novel stealth proof of concept. it could have been used in conjuction with actual malware, but the blue pill itself was not malware.

that tells me, at the very least, that the blue pill was the wrong example for ed to use. we can correct that, however, by using a better example. the race to zero would be a much better example because it involved the creation of actual malware (modifying existing malware to make something that has never been seen before is for all intents and purposes the creation of new malware), which is precisely what malcon aims to facilitate and so makes for a much closer analogy.

unfortunately, even if we replace the reference to the blue pill with a reference to the race2zero, ed's minor premise is still problematic. is the race to zero still not a good enough example? is there a better one? the fact is, no matter what blackhat/defcon presentation you select as an example you will never be able to improve the premise because it would still be just one presentation. blackhat/defcon are about more than just the race to zero or the blue pill. the blackhat/defcon conference pair focus on a wide variety of security issues, many of which not only deserve to be highlighted but also contribute to the betterment of the security condition in three well defined ways. they highlight problems that:

1. should not have happened
2. can be fixed
3. can be avoided in future designs now that we know what to watch out for.

by way of contrast (since ed's argument compares blackhat/defcon to malcon simply by substituting one for the other in his logical framework above), malcon focuses explicitly and exclusively on the advancement of malware creation which is (in general) incapable of providing the same contribution to the security condition. this is the age old distinction between vulnerability research and malware 'research'. with the exception of exploits, malware can't be fixed or avoided because it relies on properties that are intrinsic to the general purpose computing platform.

we also gain no technical benefit by supposedly trying to open a dialog between malware writers and anti-malware researchers.

• for reactive defenses the only prospective benefit would be to help analysts understand the malware. but going back as far as 2006, the average piece of malware could be processed in as little as 5 minutes, so understanding malware doesn't really seem to be something analysts need help with. 
• for proactive defenses the hypothetical benefit would be in letting the analysts know what sort of things are coming so that anti-malware products can catch them before they've even seen them. unfortunately this model is based on predicting the future precisely enough that we'd know specifically what to look for and, as such, is unworkable. the proactive defenses that work are the ones that actually know less, not more, about specific threats whether past present or future (thus why they're called generic techniques).

now, before i stray from the immediate topic any further, let's get back to ed's logical problems. the major premise that "All conferences that provide details on how to create malware are a “bad idea”" is a poor premise as demonstrated by the blackhat/defcon example. one of the necessary properties of a premise is that it's something both parties in an argument can agree on, but this premise is overly broad. as discussed above, blackhat/defcon covers a wide variety of things - can we really say blackhat/defcon is bad as a whole because one of those things might be bad? that seems pretty ridiculous. malcon, on the other hand, is much more narrowly focused on just that one bad thing; so if we rewrite the premise to be more specific, perhaps something like "All conferences that exist solely to provide details on how to create malware are a “bad idea”", then we can include malcon and exclude blackhat/defcon.

now the question one might be asking is, if ed's logic is flawed, what logic would be better? well, for starters i really don't like the major premise, minor premise, conclusion construct - i prefer the premise, inference [, inference...], conclusion construct.

• premise: malware is bad
• inference 1: since malware is bad, creating malware is bad (with the exception of benign exploits)
• inference 2: since creating malware is bad (with one exception), helping others create said malware by doing things that can reasonably be avoided is bad
• conclusion: since malcon will help people create malware by doing something that could reasonably be avoided, malcon is bad.

a malware writer's conference?

WTF? no, seriously, what the f@%k??

ever since i first read about this a day or so ago on brian krebs' blog i've been struck by the utter stupidity of this idea.

to say that such a conference would have a strong law enforcement contingent present would be stating the patently obvious.

if security companies sent representatives it would be for the same reason - not to learn from these malware writers, but to learn about them. profiling these sorts of people for the purposes of assisting law enforcement is something security researchers have been doing behind the scenes for a long time.

but even disregarding the practical complications of exposing oneself to greater scrutiny by attending, the supposed beneficial objective (and i say supposed because the site itself makes no hint at any beneficial objectives whatsoever) of helping security researchers learn about the next generation of malware is just as stupid.

anti-malware vendors do not have any difficulty figuring out malware. each of the several dozen companies out there has it's own army of reverse engineers picking these things apart all the time, and they've gotten so good at it and automated so much of it that in 2006 the average piece of malware could be processed in about 5 minutes. and since it's automated by computer, moore's law should make that process even faster now.

if (and i'm speaking hypothetically here) anti-malware companies have problems, understanding malware isn't among them. keeping up with the volume of malware is perhaps a challenge, but unless the malware writers are offering to stop what they're doing, there's little they can say or do to help that ameliorate problem.

arguably, the vendors also have a problem getting 'ahead of' the threat - which is to say that they can't assist in protecting you until after they've seen the malware (except, of course, they can - you just need to be using the right tools). the reason for this is because predicting malware (necessary if you expect a known malware scanner to be able to stop things that haven't been seen yet) is a bit like predicting the weather - no one can do it reliably. i don't see malware writers being able to help in that regard, even if they are showing off so-called next-gen malware. i also don't see them agreeing to stop performing malware q/a, which would nullify any advance in malware prediction they could offer.

last but not least, the concept of an ethical malcoder is laughable at best. comparisons to ethical hackers ignore the fact that hacker was originally a benign term that was later twisted by the media to include criminals. the term ethical hacker simply tries to highlight the benign examples that have been masked by the inclusion of a malicious set. malware creation, on the other hand, has never been benign - the most one could hope to do is highlight the non-financially motivated malware writers that have been masked by the inclusion of the financially motivated set, but those non-financially motivated ones are still pretty far from benign or ethical. until they understand their responsibility to the wider population and their impact on it and stop what they're doing, it will remain that way.

this isn't like vulnerability research, where developing exploits for newly discovered vulnerabilities serves to highlight flaws that need to be fixed. malware (in the general sense) does not depend on any flaw and thus it's creation does not provide the same benefits. advancing the state of the art of attack does not serve the common good, it is not a positive contribution and can by no means be considered ethical.