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)

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