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.

i see a standards organization

ed moyle prefaced his recent post about how AMTSO is perceived by the industry by saying that he really didn't want to continue talking about this subject (he has, after all, penned a number of posts about AMTSO recently). having seen this blog go more or less dark in the past, i have no qualms about following whatever path my interests and creativity take. if the subject doesn't bore me, i see no reason not to write about it.

and the subject of how AMTSO is perceived has a few interesting bits to it, i think. first and foremost, while david harley may bend to the notion that the use of the word "standard" in AMTSO's name might mislead people, i think the use of the word "standard" is entirely appropriate. if people are mislead into thinking AMTSO is anything like ISO, it is actually ISO and organizations like it that have mislead people into thinking enforcement has anything to do with standards. a few pertinent definitions for standard:

noun:  a basis for comparison; a reference point against which other things can be evaluated

noun:  the ideal in terms of which something can be judged ("They live by the standards of their community")

developing a basis upon which anti-malware tests can be evaluated or an ideal which testers should strive for is precisely what AMTSO is about. it is not about enforcement - following the standards is entirely voluntary. if enforcement were on the table at all then testers wouldn't participate for 2 reasons:

1. many testing organizations were (and perhaps still are) too far away from the ideal. signing up for obligations at a time when one cannot meet them makes little or no sense. with voluntary standards the obligation, instead, is to keep improving and moving closer to the ideal.
2. enforcement would mean that the standards were actually rules, and nobody thinks vendors should be involved in making rules for testers.

but apparently, as ed moyle has pointed out, the security industry perceives AMTSO as something different from what it actually is. now when you get right down to it, when people's perceptions don't match reality it's because they lack knowledge of that reality. if AMTSO were being purposefully deceptive or secretive (basically acting to deprive/deny people of that knowledge) then one might legitimately be able to blame them for the false perception problem. ed doubts that AMTSO is to blame, and so do i (mostly), but then who is to blame? let's look at an example from ed's own post. near the end he constructs some hypothetical situations where a vendor might challenge a test and then have the AMTSO review board composed entirely of employees of that vendor. he asks where the line is - i can tell him where it is, it's in the 'fine' manual. the document describing the analysis of review process states on the second page that review committee members that are employed by the challenging party must recuse themselves from participating in the analysis. this document is freely available, easy to find, well labeled and not hidden in any way. anyone who wants to learn the answer of where the line is drawn can easily do so by downloading the document and reading it - so when they don't, when they make assumptions or treat it like a questions that needs answering instead of one that's already been answered, that's really on the person themselves.

page three of that same document has something for ed as well. he asks the following:

So if it’s not the role of AMTSO to standardize, it’s also clearly not their role to accredit.  But aren’t they doing just that?

the answer is no, they are not. AMTSO makes no judgments or endorsements of reviewers or products. for an AMTSO member to suggest otherwise is considered misrepresentation. the analysis of reviews is just that, analysis. the output serves as an interpretive aid for individuals wishing to know how close to ideal a particular review was. the review analysis that ed looked at as an example (the analysis of NSS' review) was actually quite close to the ideal (though apparently not close enough for NSS' liking). only 2 real problems were found, and they've been described by members as 'minor'. in the analysis itself, the explanation for the first one even goes so far as to say that NSS' test is still better than most out there in spite of the problem. ed moyle interprets this as a pass/fail sort of judgment and i suppose in the strictest sense the NSS test did fail to reach the ideal but it's hard to say the analysis of their test is calling it a failure when it's clearly stating it's better than most out there.

of course as an interpretive aid, the reader is free to pick and choose the ideals that are important to him/her - as ed does when he discusses testing features individually. the ideal that the testing industry is trying to move towards is whole product testing. the reason is because it's understood that different products have very different technologies and thus have different ways of stopping different threats. it's especially difficult for testers to devise testing methodologies that aren't biased in favour of certain technologies. if i test feature X and product A blocks 5 things but product B only blocks 3 things, how can i possibly show that a test of feature Y shows that product B blocks everything it missed in the feature X test and product A blocks nothing because it doesn't even have feature Y? and if i can't show that then is what i'm presenting really relevant? isn't the important thing that B blocks the threats in one way or another? does it really matter if it uses feature X or Y to do it? current opinion in the anti-malware community is no, it shouldn't matter, which is why whole product testing is becoming the standard. NSS themselves bang the drum of whole product testing pretty loudly, so it seems ironic to me that they failed to test the whole product (seemingly testing everything but the spam filter).

of course, as interpretive aids go, even AMTSO's analysis isn't necessarily perfect. i say this because point 7 of the NSS review analysis is interpreted by ed one way, and a different way by myself. i don't know if ed's interpretation is correct or if the analysis is implicitly assuming domain knowledge of NSS' practices. ed quotes the following from the analysis:

Does the conclusion reflect the stated purpose? No. The report’s Executive Summary states that test’s purpose was to determine the protection of the products tested against socially-engineered malware only. Later in the report (Section 4 -product assessments) it says: “Products that earn a caution rating from NSS Labs should not be short-listed or renewed.” This is clearly a conclusion that you can’t make out of the detection for socially‐engineered malware only, as the products have other layers of protection that the test did not evaluate.

ed's interpretation is that the conclusion supposedly didn't reflect the stated purpose simply because NSS failed to include spam filters in their test. my interpretation differs in part because i know that NSS breaks malware down into 2 categories and "socially engineered malware" is only one of those categories - so making purchasing recommendations on the basis of the results of the socially engineered malware test alone seems like a premature conclusion to me. i suspect that the spam filters were only 1 of many features that weren't tested since the other malware category NSS recognizes involves drive-by downloads and other sorts of malware that don't involve user intervention. but clearly, someone who doesn't know what i know may interpret the meaning of the analysis in an entirely different way than i did.

i understand why ed feels that perception is important, but the key to making perception match reality is knowledge and understanding and there's only so much anyone can do to impart those things on others. people have to be willing to look past their preconceptions and actually acquire new knowledge and understanding.

testing testing 1 2 3

last month ed moyle published a pair of posts about an incident in which a particular piece of open source IRC server software was found to have a backdoor planted (intentionally, by an unknown party) in the source code archive on the software's official site. the backdoor wasn't discovered for over half a year and in that time the trojanized copy of the software apparently made it into the gentoo linux distribution (which has since been corrected, but if you're a gentoo user/admin and you didn't hear about this then you'll want to go check some things real fast).

all of which calls into question the accuracy of linus' law which states (more or less) that 'given enough eyeballs all bugs are shallow'.

so the question is how can you know if your flaw finders (be they auditing code to find security flaws, or testing the product to find regular bugs, or even something else entirely) are doing a good job? how can we measure it? how can we test our testers or our code auditors or whatever other flaw finders we might have? as a software developer myself, i'm sensitive to the issue of software flaws, so this was a question that interested me and almost immediately a thought popped into my head - introduce your own flaws and see how good your flaw finders are at finding them. so long as they're fully documented you should be able to remove them before the final release of the code, and by measuring how many of these particular flaws get found you can get an estimate of how good a job your flaw finders are doing.

additionally, by comparing the number of artificially introduced flaws found to the total number of flaws being found you can even get an estimate of the size of the total flaw population. animal population sizes are often estimated this way, with one exception - usually it doesn't involve making new animals. that underscores one of the biggest problems with the idea; the flaws you artificially introduce may have little in common with natural flaws, and as such finding them may not be of comparable difficulty.

when estimating wild animal populations it's more common to capture some, tag them, release them, and then go on a second round of capturing to see how many of the tagged animals are captured a second time. doing this with software flaws would necessitate having 2 groups of flaw finders (or separating the ones you have into 2 groups) so that the flaws found and tagged by one group in the first pass are used to evaluate the other group in the second pass.

2 groups are necessary because, unlike animals, flaws don't move, so the group who found and tagged the flaws are going to be a little too good at finding them the second time. ideally they should also not discuss the flaws they tagged with the other group or they could wind up giving them hints that skew the score. keeping the 2 groups really separate would be what complicates this approach and where the artificially introduced flaws would have an advantage, since those would be easier to keep secret.

a compromise where the two approaches are combined could also be possible, and if the naturally occurring flaws are adequately classified it should be possible to use that information to draft more relevant artificial flaws. in addition this would enable finer grained metrics to be collected so as to find out if there are some types of flaws your flaw hunters have more trouble with than others.

of course, this has probably all been thought of before, but just in case it hasn't i just thought i'd throw it out there.

to create malware or not to create malware

so ed moyle over at security curve has responded to some points i made in a previous post about the anti-malware community's ethical stance on malware creation.

ed's response is twofold. first he countered my assertion about what would happen if the CDC went around creating new diseases with a practical example by pointing out that some biologists actually do create new viruses. a little further on he makes mention of the concept of ethical relativity and this is important, because ethics are relative in a number of different ways. not only can ethics be relative in terms of degree (A is ethically worse than B) but also in terms of the frame of reference (the ethical rules for one group don't necessarily apply to a different group - for example there are things that would be unethical for a doctor to do but might be fine for you or i). i chose CDC specifically because, with their focus being on the control/prevention of disease, they are more analogous to the anti-malware community than biologists in general would be. if there were such a thing as computer virologists (or more specifically if there were ones who hadn't already chosen a side in the pro/anti-malware battle) they might be more in line with biologists ethically. from my perspective, though, i have to wonder if that makes them amoral with respect to malware.

philosophically (where ed's mention of ethical relativity actually came from) ed made the argument that something that is normally considered unethical might be considered alright if there was a bigger ethical 'win' as a result. what he's actually getting at is something that might be more readily recognized as the concept of the lesser of two evils. he contends that there might be scenarios in the realm of research where the good done as a result of creating malware outweighs the bad. i'm going to do something totally unexpected and agree with him, but with a caveat that you'll see in a minute.

from early on, fred cohen held out the possibility of beneficial viruses (no doubt there are even earlier citations possible but this will do), and in the beginning i thought they were possible too until i read vesselin bonchev's paper Are "Good" Viruses Still a Bad Idea? vesselin made perhaps the most salient of all points about the criteria by which a supposed good virus can be determined to be actually good. the "good" end result has to be something that can't be achieved any other way.

now vesselin had it slightly easier here because he was looking specifically at viruses, at self-replicating malware, which is a more narrowly defined problem than 'good malware' or 'good reasons to create malware in the lab'. vesselin's argument didn't leave a lot of room for good viruses - virtually everything you can think of doing with a self-replicator can also be done with non-replicative code and thus without the risks inherent in self-replication.

i mention vesselin's paper because that salient point he made extends to this case as well. unspoken in ed moyle's bank robbery example is that there is only 1 way to keep the hidden girl alive - by lying. if there were another way, would lying to save the little girl's life still be ok? if you choose the lesser of 2 evils, when a 3rd option with no evil whatsoever were available, then doesn't choosing the lesser evil mean that you're still doing evil unnecessarily?

that's where things stand in the anti-malware community. although it may be hypothetically possible to construct a scenario where malware creation is the least evil option, to my knowledge no one has managed to present such a scenario (with the exception of exploit code* for demonstrating the presence and importance of vulnerabilities), and so the no-malware-creation rule has no good exceptions yet. the need for new malware in testing (the root of the current discussion of malware creation ethics) can already be met in 2 different ways (retrospective testing or real-time/real-life testing that tests against suspect samples as they're discovered) that don't involve malware creation at all.

(* 2010/07/19: edited to add the exception case for exploit code, as pointed out by vesselin bontchev)