expert misuse of the term "virus"

in the past, the argument many experts have used against putting in the effort to actually correct people's misconceptions about what a computer virus is and what it does and how it's different from other forms of malware have centered on the idea that it doesn't really matter to a victim what kind of malware they have. when they have malware on their computer, all they care about is getting rid of it. i can understand this school of thought, even though i've never agreed with it. however, the world has changed. 

this is a post stuxnet world and defenders/victims aren't the only ones we need to consider anymore. we now have people barking orders to create digital weapons, and the details of those orders matter. if they say make me a virus then someone will make them a virus even if they didn't understand what they were asking for - and there's evidence to suggest they don't. 

stuxnet is generally believed to have been a targeted, covert operation, but it used a noisy, untargetable* type of malware - a computer virus (or more specifically a worm). there were and are better ways to achieve the ends we believe the creators of stuxnet were after, so one can only assume that high level decisions were made in ignorance of the differences between malware types and the consequences those differences would have on that type of operation.

the question, then, of whether to put in the effort to educate people about the proper use of the term virus can no longer be answered by looking exclusively at the victims who want their computers to be clean. it is now also necessary to consider aggressors who want to use malware as a weapon to serve national interests. as misguided as such behaviour is, we have to accept that it's happened and will continue to happen, and actually knowing the differences between malware types may mean the difference between a surgically precise operation, or one with a lot of collateral damage. 

this isn't to say that i think we should start helping aggressors create and/or launch their digital weapons. i still don't believe in helping the bad guys, and even if i believed such nationalistic aggressors weren't bad guys (which i don't), i don't believe there's any way to help them without also helping those who are much more unambiguously bad. what i am saying, however, is that this particular form of ignorance that experts have been too lazy to address can cause real harm and ignoring it means ignoring the opportunity to reduce the unintended harm such people will cause.

(*many believe stuxnet was highly targeted, but there's a distinction to be made. while it's destructive payload was highly targeted to a very specific environment, it's self-replication was not - it spread far beyond it's intended target)

brain - a first in so many ways

i've seen a couple of articles now about this being the 25th anniversary of the computer virus known as brain.

brain was the first PC virus in the wild. it was the first bootsector infector. it was the first stealth virus.

supposedly it was created in the (somewhat hypocritical) hopes of attacking software piracy, so the history of intellectual property maximalism has a particularly odious chapter to add.

the thought occurred to me, however (and i'm probably not the first but i haven't seen this said anywhere that i can remember), that if the stated motivation behind the virus is correct then brain is, on top of everything else, the first commercially motivated malware. before zeus, before gpcode, before adware, before the porn dialers there was the brain virus intended to get people to contact the virus' manufacturer for support.

lessons from the past

one of the criticisms i sometimes have of people in the security field is that they seem to fail to learn from the past. this isn't necessarily a fair criticism since often the people i'm directing that criticism towards aren't familiar with the past events i'm thinking of. as such this post is meant to serve a dual purpose - a) to help the people of today become familiar with the lessons of yesterday, and b) to help preserve something that i'd rather not see become a victim of the false sense of posterity that usenet archives like google's affords us. this was actually not my first choice for usenet posts to republish here, but my first choice seems to be well and truly gone.

the events described here took place some 21 years ago, back when the mores and traditions of the anti-virus community/industry weren't quite as strict as they ultimately became. in fact, i'd hazard a guess that the events described here and the lessons learned from them are at least part of the reason those mores and traditions became so strict. read on to find out what can happen when you handle malware either carelessly or even carefully but not quite carefully enough. from frisk's post in comp.virus/virus-l

From: fr...@rhi.hi.is (Fridrik Skulason)
Newsgroups: comp.virus
Subject: Two serious cases (PC)
Message-ID: <0007.9001031142.AA02943@ge.sei.cmu.edu>
Date: 27 Dec 89 12:47:52 GMT
Sender: Virus Discussion List 
Lines: 65
Approved: k...@sei.cmu.edu

Most virus researchers exchange/distribute viruses only on a strict
need-to-know basis, in order to limit the spread of viruses. However, this
does not work as well as intended. There are now two known cases where
untrustworthy people seem to have obtained viruses from researchers.

Case #1: Icelandic-1/Saratoga

     I discovered the Icelandic-1 virus here in Iceland in June this year.
     When I had disassembled it, I sent a disassembly of an infected file
     to several experts in the USA, UK and Israel, including the HomeBase
     folks (McAfee). Before I sent out the disassembly, I made one small
     change to it. This change had no effect on the operation of the virus,
     but it would make it possible to determine if a copy of this virus found
     outside of Iceland was based on my disassembly or not.

     Looking back, I can see that this was not a very good idea, simply
     because there was a possibility that somebody might select an invalid
     identification string, based on this disassembly. So, those of you having
     a copy of my disassembly, please contact me if you want to correct it.
     This change was also (by accident) included in the Icelandic-2
     disassembly, since I used the Icelandic-1 disassembly as a basis for
     that.

     Now - back to the Icelandic-1 virus.

     Three days after the virus was made available on the HomeBase bulletin
     board, in a restricted area that only a few people had access to, a new
     virus was discovered in Saratoga and uploaded to the HomeBase BBS. Some
     people thought for a while that Saratoga was an older variant of
     Icelandic-1, because it was at first said to have been found "a few
     months earlier", but this turned out to be a misunderstanding.

     Saratoga was just a minor variant of Icelandic-1, but the change I made
     was present in the virus, so it was obviously based on my disassembly.
     When Saratoga was found, I had only sent Icelandic-1 to three or four
     persons in the US - and, as far a I know, it had only been made available
     to other persons in one place (HomeBase).  They believe that the person
     responsible for the creating "Saratoga" has now been found, and his
     access to the restricted area has been terminated.


Case #2: Dbase

     The dBase virus was discovered by Ross Greenberg. It seems to have been
     planted at only a single site, because no other reports appeared for
     several months. Recently Ross made the virus available to a number of
     virus researchers. Within two weeks the first infection reports had
     started to arrive - the virus had escaped.

     We know that at least some of the reported infections were based on the
     copy from Ross, because he made one small change to the virus, before it
     was distributed. One instruction was overwritten by two "harmless"
     instructions, in order to disable the most harmful effect of the virus -
     the disk trashing part. This change is also present in some of the
     infected files that have been found recently. (In other cases the
     original instruction is present)

As I said before, I do not consider it a very good idea to make changes to
viruses, but it paid off in the two cases described above. Who knows how
many other cases of virus infections are (indirectly) the result of virus
collection/distribution by virus experts.

At least it is certain that we have to be a lot more careful in the future.

- -frisk

man 'infects' self with computer virus?

that's pretty much what the story says (read it here) and if it were true (or even possible) then it would be a pretty boneheaded thing to do. and they call this guy "doctor".

but if you haven't figured it out by now, the whole thing is complete rubbish. over 4 years ago a bunch of researchers came up with some less than amazing research that showed that certain RFID tagging systems could be susceptible to compromise by malware stored on RFID tags themselves (which i wrote about here). specifically, the data on the tags could exploit programming flaws in the back-end database the system runs off of. in essence you could write malware (even viruses or worms) that operates in the context of the database, and you could use RFID tags as a storage and distribution medium.

4 years later and another bunch of researchers (including a one dr. mark gasson)  have the (not so) bright idea to stick one of those RFID tags in a person. yeah, that really is all that happened here. that and some effective huckstering get into the media spotlight (if even only for a short while).

it really is quite unspectacular though. dr. gasson took something that supposedly contained a computer virus and then put that inside yet another container (his own body) and then called that container 'infected' as if that's all it took. by the same token i could put one of those tags in a tupperware container and call that 'infected' - and wouldn't that be something; not only 'infecting' something that's inanimate but well and truly inert. what's more, i could take one of these specially prepared RFID tags and put it between two slices of bread and make an 'infected' sandwich. i could even put one in a hole in the ground and 'infect' the planet. clearly this notion of 'infection' by containment is absurd.

but it gets a little more absurd, because dr. gasson claims to be the first. now a very clever commenter over at boingboing pointed out (here) that you get basically the same effect by sticking an infected USB thumb drive in your rectum. while you may consider that to be a juvenile observation to make, his assertion that it constitutes prior art has merit. USB thumb drives are small and portable and easily inserted into a variety of bodily cavities for the purposes of hiding or smuggling data. furthermore, USB thumb drives are notorious for hosting things like autorun worms. as such, with the bizarre "containment == 'infection'" logic being used, it's almost a certainty that dr. gasson was actually not the first human to be 'infected' by a computer virus in this (non)sense, he's simply the first to make a media spectacle of himself over the issue. (one might argue that unlike an RFID tag, a USB thumb drive wouldn't be able to pass on the infection once in your rectum - but it was never specified that the business end couldn't be left sticking out)

i can't discuss this topic without touching upon what i think is (at least partially) to blame for the ridiculous and rather scary statement being made by dr. gasson, though. it's one of my long-standing pet peeves: terminology misuse. you may have noticed my persistent decoration of words related to the word "infect". that's because it's been used in a sense that is so far from an reasonable meaning of the word infect that it doesn't deserve to be treated as a normal word. terminology misuse has become de rigeur to such an extent that even well known anti-malware personalities such as graham cluley and mikko hypponen endorse it for some terms. you can argue about natural semantic drift of words over time until you're blue in the face but technical jargon is not (and should not be) subject to the whim and whimsy of the unwashed masses (even when it comes to subjects that affect them). this particular instance of sensational absurdity is a consequence of and an argument against unfettered semantic drift in the realm of technical jargon. in no reasonable sense of the word was this person ever infected by a computer virus. absurd statements like the one the researcher is making are only possible because of slightly less absurd statements made before it that haven't been corrected yet, which in turn can eventually be traced back to basic terminology misuse.

the myth of in-the-wild prevalence

upon reading this article at ghacks.net about scanning linux systems for viruses i became aware that there are some misunderstandings over the meaning of the term 'in the wild'.

the article in question is not the only place i've seen these misunderstandings and i don't want to knock it too hard because it does advise scanning your linux systems, but the statement that

Linux is immune to viruses right? Well…mostly. Even though a proof of concept virus has been discussed, and nothing has actually made it into the wild…you still have email on your system.

fairly clearly indicates both a lack of awareness of the threat linux faces as well as a lack of understanding of what constitutes as 'in the wild'.

so let's get this out of the way early in the discussion. 'In the wild' means literally that the malware in question is active and victimizing someone or some group, somewhere in the real world. that seems like an obvious and natural definition but what isn't obvious is the implication that that has for most people. you see many people equate 'in the wild' with epidemic. they think that if something were really in the wild it would have affected a lot of people and they would have seen it personally or known someone who had seen it. they think that they can use their own experience as a measure of whether something is 'in the wild' or not. the reality is that something being 'in the wild' does not mean that that something is common enough for you to have stumbled across it - there is a wide spectrum of prevalence possibilities for 'in the wild' malware.

to that end, there have of course been linux viruses in the wild. are there still some in the wild? well given that old viruses never really die, i'm going to have to say yes. remember, rare and 'in the wild' are not mutually exclusive concepts - something can be both at the same time. once something goes into the wild it's subsequently very difficult to conclusively show it has left the wild. in fact you could say it's equivalent to proving a negative (which, as we all know, is impossible).

(note: just to be clear, i'm not talking about the wildlist from wildlist.org. things that are on the wildlist are definitely 'in the wild' but not everything 'in the wild' gets to go on the wildlist. the wildlist is a much more narrowly defined set than what's 'in the wild')

viruses on the international space station

this past week there was a lot of buzz surrounding the news that an autorun worm had infected 2 laptops aboard the international space station... i wasn't sure i was going to bother saying anything about it at first but then i decided it might serve as an interesting object lesson so let's look at what we can learn from this event and what could have been done differently....

my first reaction when reading of the event was that this just goes to show how pernicious and autonomous self-replicating malware truly is... that notion (that viruses/worms are somehow worse or more autonomous than other forms of malware) has been scoffed at in the past but viruses in space stand as a testament to their ability to get into places no one intended or would have imagined... no other form of malware besides self-replicators would have been able to find new victims in that sort of environment...

another thing we can learn from this is to stop clinging to the fantasy that the only kind of malware we need to worry about anymore is the new stuff, that old-style viruses and worms aren't worth worrying about anymore... this wasn't brand new malware, it wasn't state of the art, and it wasn't something researchers on the bleeding edge would have taken notice of even when it was new... the malware threat landscape isn't composed exclusively of novelties, there's a heck of a lot of banality out there as well...

yet another lesson is that can be learned is that for all the whining about how AV is failing, at least some of the evidence used to support that argument (in other words, some of the failures) is actually a result of not using AV in the first place, not keeping it up to date, or not following the various other best practices for AV...

actually using an AV program is the first thing the astronauts and/or NASA could have done differently... while i'm sure there are plenty of arguments for why one might not want an anti-virus program on them, such as highly critical real-time processing of experimental data, these were laptops running windows and so were already unsuitable for real-time processing ('what do you mean the OS must have been busy don't something else during that time period?')... i assume someone up there must have had AV or else we wouldn't have a name for the malware...

failing that, they could have used some other sort of anti-malware technology like application whitelisting... in fact, considering the environment that might even be a more appropriate approach since it's unlikely that astronauts need to introduce new software to those machines very often... that is unless part of their job requires them to rewrite or apply patches to software being used in the experiments to collect/analyze data... come to think of it, that might actually be the case - it's not like the folks designing the experimental payloads have a lot of chances to test and debug their software under real-world conditions when the real-world in question is actually out of this world...

the astronauts could have operated the machines under non-administrative accounts - actually there isn't really anything to suggest they didn't, nor is there anything specific to an autorun worm's replication technique that should require administrative access... despite a previous post i made highlighting the ways in which least privilege can fail to stop malware, it still is fairly effective against a lot of existing malware...

they could have disabled autorun on those machines - in fact, they probably still should disable it... autorun is purely a convenience feature for the technologically inept; hopefully that's not the sort of folks NASA is sending into space (then again, they did get infected by somewhat old malware)...

finally, they could have used something other than windows machines... although technically not immune to malware, macs and linux machines have a far smaller pool of threat agents to worry about and the lower population density means that they are less connected to other similar endpoints that could pass on something they'd be susceptible to... of course, once again this is likely subject to what the machines are being used for - if they're running or monitoring experiments with them then they may be stuck with whatever the people who designed those experiments wrote their software for (and considering the cost of doing anything in space, cutting corners on the ground and using cheap windows developers is pretty likely)...

according to NASA this is not the first time they've had a virus infection in space... let's hope they also look at these sorts of events as learning experiences and figure out how to do things better in future...

the future of malware past

in the two most recent posts on eset's threatblog david harley has been talking about old malware... i don't just mean a couple months or even years old - seriously old malware from over a decade ago that none-the-less continues to cause problems for people...

in the first post david asked how this could be (and in the second pointed out that my answer was to more of a 'why' question than a 'how' one - just the kind of kick in the butt i need to remember to think twice and speak once)...

indeed, if you've got an on-access scanner you ought to be protected from old malware without even thinking about it, right? that simplistic view is certainly what most people have learned but if the infected disk isn't accessed until the computer is booting (a time when neither the on-access scanner nor the operating system itself are loaded yet) then that same simplistic view is proven to be a false sense of security...

that being said, the reason people don't think about or talk about or otherwise take special cases like this into consideration is the widespread (and false) belief that malware eventually becomes extinct... i've already stated numerous times that old viruses never die but what harm could that little mental shortcut really do? well, for one thing when left unchallenged it becomes a dominant pervasive belief... a belief so strong that certain best practices and safe hex behaviours like manually scanning disks before using them even though they're from your own backups or changing the boot priority in the BIOS to prevent possible boot sector infectors from getting an opportunity to execute fall out of common use and knowledge... a belief so strong that vendors may actually remove virus signatures from their signatures databases for performance reasons and eventually allowing viruses that have no good reason to still be around to once again cause problems for many people...

on the other hand, there's no way any reasonable person would accept a belief system that says old malware remains as much a threat now as it did when it was first released, so how should we think about this problem? i suggest that we think of old malware the way we think of landmines - long forgotten and unused but not entirely gone, and one false step and you may be hosed...

this goes for all malware, however one may rightly suggest that some malware won't age as well as others... malware that relies on some sort of infrastructure probably won't do so well in 10 years (when it's command and control network no longer exists or no one's listening to the domain it sends it's logs to)... older (pre-commercial) malware didn't tend to rely on such things though and viruses (due to their infectious nature) are more likely to find their way into backups and so be re-encountered weeks/months/years later... BSI's specifically may well prove to be the longest lived in practice because of their independence from and execution priority over the OS or most any other software component of the system... and of course since they're some of the oldest viruses (the first pc virus was a boot sector infector) and one of the first types to fall out of fashion, and since they're still causing problems, they're already off to a fine start...

foolishly forgetting or recklessly ignoring the the threat posed by old malware will ultimately make utilizing backups, archives, and just plain old media a bit like strolling through a minefield without a map... old malware won't go away, it will just lie dormant in the nooks and crannies of the computer world until we take that one wrong step and it comes back anew...

an inconvenient truth about race to zero

from noah shiffman's article av vendors race-to-zero clue:

New viruses will not be created and no modified or variant code will be publicly released.

it's amazing to me how many people don't seem to realize that when you modify something you are effectively creating something new... this has been one of the more prevalent misunderstandings i've seen from people in favour of the race to zero contest at defcon this year and one i really didn't expect...

now, i realize i haven't always had as good a definition of variant as i do now... i should be more understanding of people who may not know as much as i do on the subject of malware... but even long before my understanding of variants reached it's current state i still had the logical capacity and intuition to realize that when you modify a virus, especially when you modify it to the point where anti-malware products can no longer detect it, then it is no longer the same as the original virus, it is no longer like anything anyone has seen before, it is (dare i say it) new...

the only way the race to zero won't be producing new virus variants is if cdman83 is right about them probably not using actual viruses in the first place (we can only hope they were dumb enough to misuse the terminology)...

even then, though, they will still be producing new malware... creating new threats is really all this contest will accomplish... demonstrating that known-malware scanning can't detect things that no one has ever seen before (ie. things that aren't known) is like demonstrating a spoon can't cut through bone...

race to zero in the security special olympics

news has started floating around about a contest in virus obfuscation being held at defcon this year... there have been a couple of mentions of it elsewhere as well, such as robert graham's "race to zero" post, sunnet beskerming's post "defcon competition has antivirus vendors complaining", and even an ars technica post titled "antivirus vendors pan free research from defcon contest" by david cartier...

now i'm obviously opposed to this and think it's irresponsible and unethical... not to mention they've chosen just about the worst malware type to play with - viruses... note to contest organizers, participants, and proponents: in the event that something goes wrong, self-replicators have a tendency to go on and on and on long after they are released or spread (old viruses never die)... they aren't called viruses because they make your computer feel bad, they're called viruses because they spread by themselves just like any infectious biological pathogen... this contest and those in it aim to play with fire...

with that out of the way, it's time i got to debunking a lot of the wrong thought surrounding this contest...

contest organizers (as quoted by pcworld):

Contest organizers say that they're trying to help computer users understand just how much effort is required to skirt antivirus products

if i'm not mistaken one of the key aspects to presenting things is to know your audience... the computer users at defcon already know it's easy to evade a scanner...

race to zero website:

The event involves contestants being given a sample set of viruses and malcode to modify and upload through the contest portal. The portal passes the modified samples through a number of antivirus engines and determines if the sample is a known threat.

this is a logical failure... a modified sample is by definition not a known threat until such time as a signature has been added to the scanner... if you're going to put on this kind of contest you might want to make sure you know what the difference between a known and unknown threat are...

Signature-based antivirus is dead, people need to look to heuristic, statistical and behaviour based techniques to identify emerging threats

this represents a complete failure to understand what the heck they're testing... changing a single bit can often foil signature detection - for contestants to get anywhere in this contest they will have to foil the heuristic, the statistical (also arguably a heuristic), and the behaviour based (heuristic here too) techniques that the scanners also implement... there are no naked known-malware scanners anymore (at least not as far as consumer products go), they all have some kind of heuristic engine in them...

Antivirus is just part of the larger picture,

and this is failure to understand their own messaging/marketing... how can anti-virus be part of the picture if it's dead?... on the one hand they want to tear down the practice of using anti-virus (anti-virus is dead) and on the other they expect people to keep it around as part of the picture... someone needs to make up their mind...

We are not creating new viruses

contrary to their mistaken belief, modifying existing viruses until such time as they're different enough from the original that neither known-malware scanning nor heuristics can recognize them is creating new viruses...

modified samples will not be released into the wild

one wonders how precisely they're going to keep that from happening? they're presenting contestants with samples, not a locked down environment that prevents them from taking their samples with them at the end of the day and doing something stupid/careless/malicious with them after the fact... how do i know this? because providing that kind of environment would be prohibitively expensive and restrictive... it might work in an educational institution (where the costs are offset by student tuition) but not as a contest..

robert graham:

The 'protectors" (product vendors) have big marketing
budgets to tell us their side of the story

it's not their side of the story, it's their attempt to get people to buy their product... on some level we all know that marketing and advertising is just another kind of lying... you don't honestly believe a whopper looks as perfect and juicy in real life as it does on tv, do you? then stop being disingenuous by treating av marketing as anything more factual than that...

We only get one side of the story

that is bullshit... we hear about the failures of anti-virus all the time, we hear about people giving up entirely on anti-virus, and we hear about anti-virus being dead... we get a lot more than just the vendor's side...

Yet, such contests also help customers

defcon isn't a customer education setting, this contest isn't going to teach them anything because they aren't going to be there...

The educating needed here is that the mainstream anti-virus technologies are easily evaded, and that such evasion happens a lot

if it happens so much then why do people need to be educated about it? surely they'll have seen it for themselves or they'll know someone who's seen it and has related the story to them?

Anti-virus vendors publish tests "proving" a 99% detection rate

this is the point where one realizes that robert graham is playing the part of an uninformed crank... anti-virus vendors do not publish tests like that... that kind of self-serving behaviour would absolutely NOT be tolerated by competitors or by the community... vendors point to tests carried out and published by independent 3rd parties...

However, that doesn't apply to customers. Often, the best way to test an anti-virus product is to create your own virus.

this is beyond stupid... you don't test your airbags by smashing your car into things and you don't test your anti-virus product by making new viruses... you leave such testing to the people with the expertise and resources to do it properly... customers generally have neither...

sunnet beskerming:

It should also show up the antivirus tools that
are making use of poor signature detection mechanisms

just like the race to zero website, this is a failure to understand what the contestants will really be bypassing... in order to not be detected by the scanners the samples will have to bypass the heuristic engines in those scanners... getting past a good signature scanner can be as easy as changing a single bit (because a good signature scanner will be very exacting so as to avoid false alarms)...

and those that are using weak heuristics to detect previously unknown malware.

heuristics have to be weakened in order to reduce the number of false alarms to an acceptable level... customers are generally unprepared to resolve potentially false alarms...

It is strange, though, how competitions like CTF, or the recent 0-day competition at CanSecWest, do not attract much complaint, but as soon as antivirus or antimalware tools are targeted it is too much for people

an interesting point, but one that highlights the fact that those other contests revolve around software flaws, whereas showing that new malware doesn't get picked up by blacklists is no more a flaw than notepad's inability to act as a hex editor...

david chartier/ars:

Instead of trying to deride Race to Zero, the AV industry could have a chance at working with the contest to harness what, in reality, could turn out to be some of the best research available on new malicious techniques. "You get what you pay for," as the old saying goes, but in the case of Race to Zero, the AV industry could be passing up a veritable gold mine of free ideas on how to better fight new threats.

except there's nothing for the av industry to learn from this contest... it's already known that malware can be modified, it can be modified in a countably infinite number of ways and if you protect against one the bad guys will just choose (not even find, choose) another... uninformed people think that things would be different if we used heuristics or behaviour blockers or application whitelisting, but the reality is that those can be bypassed in an equally numerous ways... their failures aren't discussed as much because because few people make use of them except for heuristics... and as far as heuristic failures
go people just misinterpret that as a failure in signature scanning, as most people involved in or commenting on this contest have already done...

to repurpose a train of thought from the riskanalys.is blog, the chance of any malware authors coincidentally creating the same malware or using the same modifications as the participants in this contest is basically 0 (n/infinity) so the value of trying to anticipate malware creation/modification techniques and use that knowledge for prevention is also generally 0... conversely, the chance of malware creators/users making use of what is revealed by this contest is greater than zero (because they're lazy, just look at eeye's bootroot to see an example of this having happened) so the value in adding detection for these new samples after the fact (or better still, avoiding the creation of those samples in the first place) is greater than zero...

ultimately i'm reminded once again of something david harley wrote some time ago... he hit the nail on the head when he said the rest of the security industry still doesn't understand av technology, practice, or issues - what people (including the contest organizers) have been saying about this contest proves that much... worse still, robert graham's maligning the credibility of vendors with false statements underscores one of david harley's other points; that the av industry and community remain hugely untrusted...

one has to wonder about the security industry when it doesn't understand one of it's oldest segments (and it's not like the information and people involved aren't available)... the mistrust, on the other hand, is completely understandable under these circumstances - you fear/hate what you do not understand, after all... schneier recently stated that the security industry would be coming to an end and i'll admit i had a bit of a knee-jerk reaction to that (though not so much that i wrote about it - if i did that everytime i disagreed with schneier . . .) but rothman (i think) made a subtle change by saying that security as we know it will come to an end... that's a possibility i almost look forward too - not because i think security should be subsumed by other things, but because the things i'm seeing make me think the security industry has become fundamentally broken (and/or gone mad)... of course, long time readers might recall i have my own prediction about security...

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

digital signatures vs file infecting viruses

so joanna rutkowska actually talks about things other than so-called rootkits... this time (i won't link to the article for known reasons) it's file infecting viruses...

from the article:

But could the industry have solved the problem of file infectors in an elegant, definite way? The answer is yes and we all know the solution – digital signatures for executable files. Right now, most of the executables (but unfortunately still not all) on the laptop I’m writing this text on are digitally signed. This includes programs from Microsoft, Adobe, Mozilla and even some open source ones like e.g. True Crypt.

With digital signatures we can "detect" any kind of executable modifications, starting form the simplest and ending with those most complex, metamorphic EPO infectors as presented e.g. by Z0mbie. All we need to do (or more precisely the OS needs to do) is to verify the signature of an executable before executing it.

I hear all the counter arguments: that many programs out there are still not digitally signed, that users are too stupid to decide which certificates to trust, that sometimes the bad guys might be able to obtain a legitimate certificate, etc...

But all those minor problems can be solved and probably will eventually be solved in the coming years. Moreover, solving all those problems will probably cost much less then all the research on file infectors cost over the last 20 year. But that also means no money for the A/V vendors.

first things first - this is essentially a whitelist technique (with the added bonus that the cryptographic component allows the proof of whitelist membership to be shipped with the file instead of requiring a lookup in a very big list) with all associated fundamental problems... think the problem of signing all good programs is small and will probably be solved? maybe for suitably large values of small... if you're going to focus on identifying good files instead of bad ones you have to keep in mind that the good files outnumber the bad by orders of magnitude and grows at an even faster rate... conceptually signing all good programs is simple, but in practice it's very, very hard...

but let's assume we do solve that problem... so if the file isn't signed then it doesn't run and if the file's signature is invalid then it doesn't run... the presence of a valid signature is assumed to mean that the file is a) not bad and b) hasn't had anything bad put into it after signing, but is that a valid assumption? given that mobile spyware can get digitally signed by symbian, i think not, at least not for the first part of the assumption... currently digital signatures like the ones joanna holds up as examples are meant to prove authenticity, not safety... putting the onus on the signatories to determine whether the code they're signing is safe doesn't solve any malware problem, it just offloads it onto the signatory... this is also not a small problem: distinguishing good from bad is and always has been the problem and offloading it onto someone else doesn't make it any easier to solve...

the second part of the assumption, that verified signature implies nothing bad has been put into the file, may well be true, assuming that the verification system itself hasn't been compromised... the digital signature proves authenticity and one of the prerequisites for authenticity is integrity and that's really the underlying ingredient here - managing system integrity... any application whitelist worth it's salt already keeps track of the integrity of the executables on the whitelist, otherwise it would be trivial to fool it by simply replacing a whitelisted application with a piece of malware with the same filename... but as yisreal radai showed in his paper "integrity checking for anti-viral purposes: theory and practice" (sorry, no suitable non-vx links at this time), systems that detect changes to the integrity of files are subject to attack and one based on digital signatures is no different... the signing key could be stolen (there's been malware designed to steal cryptographic keys in the past) and then generating valid signatures for infected files would be trivial, the key used to verify the signatures could be altered (either on disk or dynamically in memory) by a malicious process that has already been signed, or if the system allows adding new keys then one could be added maliciously that would allow the files to be modified (infected) and then resigned with the new key to trick the system into thinking the file's integrity is intact... in fact, taking a cue from the developers of stealth technology under windows, one could simply change the result returned by the signature verification function... in order to be immune from attack, an integrity checking system has to be offline and out of reach of the attacker, and that's not compatible with a system that checks integrity in real-time to prevent modified files from running...

of course there are other problems too... it's not just deciding what to sign, ensuring the signatures are themselves trustworthy, and finding the resources to sign every good program in existence... there's also the classic whitelist problem of deciding what to do in an environment where programs are being created (or even what's a program in the first place)... are we going to digitally sign word documents? yes? ok, and will that stop macro virus infection? no of course not... there are plenty of macro viruses that infect a document when the document is saved - a point at which a new digital signature would have to be created anyways... then when the person we send the document to opens it the virus runs and then proceeds to infect documents that person creates or modifies (and then signs) and so on and so on...

again, from the article:

So, do I want to say that all those years of A/V research on detecting file infections was a waste time? I’m afraid that is exactly what I want to say here. This is an example of how the security industry took a wrong path, the path that never could lead to an effective and elegant solution. This is an example of how people decided to employ tricks, instead looking for generic, simple and robust solutions.

unfortunately a digital signature based whitelist is no elegant solution either... whitelisting for anti-viral purposes dates back at least as far as thunderbyte anti-virus and there have always been ways to manually check the integrity of transfered files to make sure they haven't been altered from what original vendor was distributing by using crc's, hashes, and even digital signatures... a digital signature based whitelist makes certain aspects of usage a little more convenient, but it doesn't mitigate the inherent problems of a whitelist...

joanna may have wanted to use this to demonstrate the way security solutions ought to be in an ideal world, but the world is not ideal, and the virus problem as well as the many varied ways of addressing it are not as simple as she portrays them... thus her example of security gone wrong has no legs... in the real world there is a counter-measure for every protective measure, and elegance (subjective as it is) cannot be the basis upon which the measures we take are judged...

old viruses never die

the wildlist is often seen as the definitive reference for what viruses are in the wild, so much so in fact that a special form of 'in the wild' (ItW) that has become synonymous with in the wild according to the wildlist...

not long ago, however, i heard and interesting and fairly reasonable criticism of the wildlist that brought it back down to earth... that criticism was something along the lines of there being a reporting bias in the wildlist where some viruses, though active in the wild, aren't reported on the wildlist because anti-virus products remove them without incident when they're encountered... when you consider the fairly finite list of trusted people who report to the wildlist and the fact that there's really no reason to draw the attention of any of them to a virus that any trained monkey (armed with an anti-virus product) can get rid of it's easy to see how many viruses could go unreported on the wildlist...

this means that the lifespan of a virus can not really be measured by how long it stays on the wildlist... this in turn means that a virus that is on the wildlist for two years did not necessarily last longer than a virus that only stayed on the list for one year...

my favourite example of a long lived virus is stoned.empire.monkey; it was on the wildlist for over 10 years, few viruses can boast such longevity... one of the reasons it stayed on the list so long is because monkey was not as simple to remove as other viruses (especially other boot sector viruses) in it's day - the generic advice involving fdisk had unintended consequences (loss of access to your data) where monkey was concerned because monkey moved and encrypted the original uninfected MBR... this meant that instances of monkey infected computers were much more likely to be brought to the attention of a wildlist reporter somewhere...

however monkey disappeared from the wildlist sometime in late 2003, presumably because the environments in which it could thrive were gone (boot sector infectors generally can't spread in the 32bit windows environment that was introduced some 8 years prior to monkey's disappearance from the wildlist)... in spite of anti-virus products being able to detect and remove monkey for almost if not the entire time it was on the wildlist, av programs did not seem to be able to drive it into extinction any more than the fox could drive the rabbit to extinction in the classical biosphere models found in highschool biology textbooks... instead, loss of habitat seems to have had the biggest effect in killing off not just monkey but the entire class of boot sector infectors...

it's entirely likely that monkey is not alone in this respect... if detection and removal couldn't drive monkey to extinction, why should they drive any other virus to extinction?... given the reporting bias of the wildlist suggested earlier, it's quite likely that many viruses still go about happily infecting unprotected computers and being easily zapped when they encounter av so that there's no report of their activity - that they continue spreading just under the radar until the environment on which they operate is gone and for most virus classes that kind of loss of habitat hasn't actually happened yet...

in fact, it's debatable whether there's even been complete loss of habitat for boot sector infectors like monkey... just last night this blog was visited by someone doing a google search on the keywords 'stoned.empire.monkey.a removal' (i hope they found killmonk, the dedicated monkey removal tool)... my guess is that, since boot sector viruses are considered extinct, nobody bothers with the safe hex steps that mitigate the risk of boot sector infection (ie. changing the boot sequence for the computer) so old floppy disks are re-introducing the virus to active machines, and/or maybe (just maybe) some of the machines out there are still running dos...

grey goo strikes again

looks like one of the more interesting things in security blog land today was a service outage over the weekend in second life caused by the infamous grey goo (virtual virus hits second life, grey goo hits second life, worms in second life, security, a human problem)... i'm not sure why they all chose this particular time to take notice of the grey goo in a malware context but at least now i know i'm not the only one who thought it was an interesting instance of game-related malware...

this particular case was pretty unremarkable, though, unless you take the golden rings (from sonic the hedgehog) into account... otherwise it really wasn't a big deal - it's not the first time and it's not the worst time... presumably the first time was the worst time because linden labs hadn't yet developed tools to cope with the problem of self-replicating code in the game, but now they have and this latest case saw new logins blocked (if you were already in the game you could generally stay in) for less than half an hour while they cleaned up the mess (as opposed to the head scratching and long-delayed resolution they went through when the problem first came up in october of last year)...

of course there's more to the story of grey goo than most seem to be reporting... last month i wrote about it, about it's classification, and about the counter measures linden labs developed - essentially behaviour blocking technology... the fact that grey goo continues to pop up from time to time illustrates the broader principle that behaviour blocking can't completely solve the virus problem... i suspect that the quick cleanup this time points to what essentially boils down to a signature based removal technique as well (which, for the time being at least, is a perfectly reasonable way to recover from the special cases that get around the primary defense), so linden labs continues to be an interesting example of anti-malware techniques and technology developing in the apparent absence of but parallel to the anti-virus industry...

ipod viruses

lots of people have been posting about the fact that apple let a virus slip into it's video ipod product line... a lot of them were rightly ticked off at apple's disingenuous attempt at passing the buck to microsoft for not making their OS "more hardy", and i could certainly parrot that sentiment if i wanted to be a parrot (it certainly wouldn't be the first time i held apple's feet to the fire over malware issues)...

but there's a small kernel of info that was shaken loose that doesn't really seem to have gotten the attention it deserves... see, as much as i enjoy finger pointing, i think this incident (and the similar cock-up by mcdonalds in japan) is an excellent object lesson for the average user about an old malware issue that has been all but forgotten in this day and age - that being that removable media represents a potential infection vector...

oh sure, nobody's making bootsector viruses anymore, and floppy disks are becoming extinct so the traditional threat we used to think of with regards to removable storage media is a non-issue, but removable storage media has evolved and the malware risk has evolved with it and in some ways gotten worse (autorun anyone)... the more things change, the more they stay the same...

if it can store data (like songs or video or whatever) then you should think of it as being as dangerous as a floppy disk used to be... whether it's an actual floppy disk or cd or dvd or flash/pen/thumb/usb drive or mp3 player or media player, so long as it's new to your system it needs to be scanned for malware before anything on it can be used or executed (and that means you should probably disable autorun - as inconvenient as that sounds)... otherwise you have to deal with things like worms infecting your pc as soon as you connect your shiney new ipod to it...

the virus problem is solved... NOT!

years ago (in 1988 if i'm not mistaken) peter norton (of norton utilities fame) famously stated that computer viruses were an urban myth, like aligators in the sewers of new york... even though he didn't really have much to do with it's development, it's still quite ironic that an anti-virus product bearing his name (norton anti-virus) and at one point his likeness has become one of the dominant forces in the anti-virus industry...

now, john thompson (ceo of symantec, maker of norton anti-virus) is being quoted as saying that the virus problem is solved... if you're wondering - that would be the sound of my irony meter being blown to smitherines from an overload because after 18 years norton-related irony has come full circle...

i don't know what world john thompson is living in or what his special definition of solved is but it seems to me that if people are still having problems with viruses then the virus problem isn't solved...

the virus problem is fairly clearly not solved, so how are we to interpret claims that it is? well, one conclusion that we can draw is that if symantec thinks the problem is solved then they can't have any vision for future innovation in the anti-virus domain - after all, you wouldn't call something solved if you were still in the process of coming up with better solutions, would you?...

if they were just changing their focus to more socially engineered attacks like phishing and fraud instead of traditional malware as has been suggested (in spite of the fact that malware remains a great enabling technology for those other kinds of attacks), then why try so hard to divert attention away from the virus problem? why say something they know isn't true (and i'm pretty sure they know the virus problem isn't solved - they aren't dummies) unless there's something they're trying to hide (like a lack of vision, or perhaps a belief that they aren't going to be able to be nearly as successful in the av industry in the future as they are now)...

whatever's going on, saying the virus problem is solved is a statement that should engender mistrust, not just because it's blatantly false but because it's likely some kind of deception (like a magician or street hustler employing the art of misdirection so that you don't notice the trick)... something just doesn't feel right about it...

second life's 'grey goo'

i don't play second life myself (i don't know how people find the time) but i caught wind of an interesting story last week by way of boingboing.net about self-replicating objects inside the second life game...

pat yourself on the back if you think this is going to wind up with me labelling them viruses - but not too hard (you might break your spine) since this is a virus related blog...

yup, it appears that users can make their own objects in second life and code behaviours into those objects with a scripting language... that makes them, essentially, programs... and those second life objects that self-replicate? well they're self-replicating programs, which fits the academic definition of virus like a glove... apparently there are a number of different grey goo incarnations (since counter measures were developed and deployed) but i haven't found any descriptions yet that could be interpreted as a program infecting another program, so i would probably classify the grey goo as a kind of worm (more specifically i suspect it might qualify as a rabbit)...

one of the things about this that is interesting to me is that this is a departure from the other stories one often hears about regarding internet gaming malware... generally the malware one hears about is a password stealer or some other kind of spyware meant to enable the attacker to steal something of value... they're held up as examples of how malware today has become financially motivated (so-called crimeware)... as near as i can figure, however, there's no direct financial benefits to grey goo attacks - if anything they seem more like the vandalism stage of malware we used to have and perhaps it's good to remember that technically that hasn't really gone away yet (obviously)...

some folks may disagree with the vandalism charactization - after all, in the real world grey goo would qualify as a weapon of mass destruction... second life isn't the real world, however... the grey goo in second life doesn't consume other in-game resources like real world grey goo would (which makes it both more benign and in some senses harder to control) - the only resources second life grey goo consumes are the computing resources of the game servers, effectively executing a DoS attack on the game... nobody dies and nobody's in-game character dies; at most it really just brings the servers down and interferes with in-game commerce (which has apparently branched out into real-world commerce but interfering with that wouldn't really qualify as mass destruction)...

another interesting aspect are the counter measures that have been developed to combat the grey goo, particularly because they were developed in-house at linden labs (creators of second life) rather than by the anti-virus community and because they seemed have come up with familiar solutions in spite of not being part of the anti-virus industry and probably not even thinking of it as a viral problem... one blog commentor shudders at the thought of writing an anti-virus to address the problem and yet that's exactly what linden labs did with their grey goo fence... of course it's not what the average person would consider an anti-virus, it's not a signature based known virus scanner (perhaps because the anti-virus industry has done such a poor job of image control that the idea of creating a conventional scanner for this problem was anathema to the developers), it's a behaviour based system that triggers on excessive instantiation (rezzing) within a family of objects (too many children in too short a time is bad)...

one key thing to point out is that behaviour based systems (like all preventative measures) are not perfect and the grey goo fence is no exception... apparently second life requires objects to be able to instantiate other objects so some level of self-replication is always going to be able to get in under the grey goo fence's threshold... additionally it might be possible fool family membership evaluation (perhaps by socially engineered player intervention)... at any rate, the grey goo fence has failed and a new counter measure being suggested is limiting some of the scripting functionality required for self-replication so that only trusted individuals can make use of it - which is essentially a kind of whitelist... whitelists won't be a silver bullet either, of course, because there is a limit to the accuracy and scope to which one can objectively define trust...

it'll be interesting to me to see where this kind of in-game malware proceeds - whether truely infectious self-replication emerges, whether other types of malware-related techniques are employed... it almost makes me want to play the game and see it first hand... almost...

corrections for cytrap labs blog

here we go again... ok, this particular blog didn't accept my comment at all so instead of getting the text out of historical feed items for a comment aggregator feed i got them out of a backup i saved in google notebook (i backup my comments before submitting because i occasionally encounter problems during comment submission and need to resubmit)...

the article in question is Do not believe everything you read but you should reflect on it - anti-virus software tests which was about (you guessed it) the consumer reports controversy... my comment was as follows:

"This is more scientific than the test method used by Independent Security Evaluatiors (ISE) used by Consumer Reports to conduct these tests on its behalft?"

yes, retrospective testing is more scientific than testing with lab-made viruses... retrospective testing uses viruses from the real world while ISE's test used viruses meant to approximate those from the real world (ie. it simulated the processes by which viruses are created in the real world based on a variety assumptions which may or may not be valid)...

"A 40% detection rate in a retrospective test is seen as being pretty good for most anti-virus software because it means that it detects all the new malware appearing during 3 months by heuristics and generic detections."

??? 40% detection rate means it detected 40% of the viruses, not all of them... it's considered pretty good because most do much worse than 40%...

"Using currently-known viruses to measure the performance of older AV engines is based on the assumption that the viruses we know about today will be the same kind as those that we will see in the near future. Hence, what was unkown three months ago should be representative of new viruses in general?"

the only assumption here is your own that retrospective test results are supposed to be generalizable... the reason retrospective tests (and other tests for that matter) are performed over and over again is precisely because they are not individually generalizable and a general sense of how well a product does can only be gained from looking at trends across multiple tests...

"Just for the record, zoo viruses are commonly defined as “existing only in lab environments” and thus not ITW (in the wild) until leaked. If they only exist in lab environments, what might their origin be?"

just for the record this is an oversimplification of what zoo viruses are... they do not exist only in labs, they are simply believed to not be actively spreading in the wild... they can still exist all over the place, in vendor labs, in private collections, or in the hot little hands of those who simply haven't gotten around to trying to spread them yet...

"Further, where is the line to be drawn at “vendor created”? Vendors get viruses in various ways but sometimes provide compensation to people providing them (e.g., also called vulnerability research). Examples of this can be found in the Perrun JPEG virus proof of concept and the Commwarrior.a SymbianOS virus."

if those are supposed to be examples of viruses whose creators were compensated by the vendors then i think you need to provide some proof... although a certain famous name in the av industry is believed to have paid for viruses, that was a long time ago and those efforts helped him become a pariah in the av industry and community...

"The AVIEN open letter:
>Public letter concerning the Writing of Viruses & How it Does Not Teach about Virus Prevention (May 30, 2003)
is not necessarily very helpful. I even wonder why some of these well known av industry representatives let their name stand on this letter."

consider reading the signatures more closely - they are not just av industry representatives, there are lots of people on the list that are outside of the av industry...

" > “…it is not necessary and it is not useful to write computer viruses to learn how to protect against them.”
One could interpret this statement as saying something similar to: trust us we know best and do not need to explain ourselves to people like you."

or you could interpret it as simply the result of a great deal of online discussion that occurred elsewhere (in multiple venues)... petitions generally don't include all the conversations and arguments that lead up to their creation...

and that pretty much covers all the corrections i have saved up... for now...

corrections for the virus alert blog

i'm always on the lookout for good new sources of malware and/or security information, especially blogs (growing a security blogroll as big as mine doesn't just happen, y'know)...

now sometimes i find a good one and sometimes i find one that could use a little work... the virus alert blog is one that that i thought could use a little work so i offered some corrections to a couple of articles that i felt held the most misinformation... i don't think the comments i left were overly critical, more just corrective... certainly not something anyone should take offense to - but apparently offensive enough for them to be taken down without explanation or correction to the articles in question...

well, isn't that just dandy then... y'know, i respect the right of a blog owner to decide whether or not s/he wants to accept feedback from others... look at me, i've disabled comments here in part to avoid comment spam but also to avoid being engaged in complex debates in a medium that frankly just wasn't designed for it (which is why i point people to alt.comp.virus and alt.comp.anti-virus)... i still accept feedback, mind you, and even make corrections from time to time based on that feedback, just not in the form of blog comments... but if you're going to allow comments then allow comments, don't disappear them...

whatever... thanks to my use of comment aggregation (via co.mments.com) and a feed reader that keeps track historical feed items i have the full text of my comments to share with you...

the first article was Computer Virus Myth #5 which basically said getting infected by viewing a web page was a myth and not possible... my response was as follows:

By kurt wismer. October 5th, 2006 at 7:59 am

while it would ideally be true that you cannot become infected just by browsing to a web page, the reality isn't so simple…

there are multiple examples of malware getting executed on a host machine simply because a user browsed to a malicious website - adware and spyware do this all the time so there's no reason why a virus can't do the same… if the virus can get executed (and the spyware example you yourself acknowledge proves that software can get executed under this scenario) then the virus can infect the machine…

in fact, one type of instant messaging worm spreads itself by sending messages to your IM contacts containing nothing more than a link to a malicious website which, when visited by your contacts launches the viral on their machines…

so long as there is java, javascript, activex, flash, shockwave, and any number of other active content web technologies out there (not to mention vulnerabilities that allow arbitrary code execution), any kind of malware can get executed by browsing to a malicious page - and for viruses that means they get the opportunity to infect…

("launches the viral on their machines"? looks like i missed a word - should have been "launches the viral code on their machines")

the second article was The 3 Main Types Of Computer Viruses which lists trojans, worms, and email viruses as the 3 main types of (ahem) viruses... my response was as follows:

By kurt wismer. October 5th, 2006 at 8:35 am

this really begs some corrections…

first and foremost - a trojan isn't any kind of virus… although viruses can often be considered a kind of trojan, the reverse does not hold true… the fundamental requirement for a virus is that it self-replicates and there's nothing in the definition of trojan horse programs dealing with self-replication…

worms can be considered viruses but generally only in the academic sense (whereby the mathematical definition of virus used in formulating proofs includes all self-replicating programs)…

email viruses are more accurately referred to as email worms… the tradition with viruses is that they are classified by what and/or how they infect (what: boot sector viruses, file infectors, macro viruses, etc - how: overwriting infectors, appending infectors, companion infectors, cavity infectors, etc)… "email" is neither a 'how', nor a 'what' (since email is not any kind of program it cannot be infected, it can only serve as a container), it is a transport medium (which is how worms are generally classified; email worms, IM worms, IRC worms, P2P worms, etc)…

diebold voting machine viruses

i saw a lot of articles about the recent research done on the potential for malicious code injection and vote stealing on the diebold accuvote ts voting machines but there was one kind of article i was expecting but never saw...

you see, the researchers claimed to have created a virus for the voting machine as part of their research - so where's the outcry from the anti-virus community about that? there doesn't seem to be any (and i have web searches on virus/worm/trojan/{as many other malware terms as i can fit in a search query} redirected to my feed reader so i'm pretty sure i would have seen something if there was something to see) and that seems kind of peculiar when compared to the reaction to the consumer reports av tests...

what could be the cause of the silence? do they only care about virus creation when it serves as a handy way to deflect criticism that makes the vendor's product look bad? the fact that vendors whose products weren't tested by consumer reports also raised a stink about the virus creation, and the fact that the anti-virus-writing public letter most often cited was originally in reference to a university course that advertized virus writing as part of the curriculum, both suggest that the community's concern over virus writing is not as narrow and self-serving as the nay-sayers would have you believe...

maybe the security researchers involved in the voting machine virus creation are somehow beyond reproach? well, some people thought the security personalities involved in the consumer reports test were beyond reproach too, so that shouldn't be it either...

maybe the technical circumstances of the voting machine virus nullify the threat it poses? [sarcasm] because a virus that can only infect voting machines (that run windows) wouldn't really be a threat to the public if it fell into the wrong hands - it's just a threat to democracy... [/sarcasm]

well, i'll tell you what - i can't speak for anyone else in the anti-virus community, but if they're anything like me, maybe they just didn't know what to think at first, and as time wears on it becomes easier and easier to just let it go... when i first read the headlines i wasn't sure what to think - on a very basic level i felt uneasy about it but i wasn't sure if that was just a knee-jerk reaction so i waited for some anti-virus type who knows more than me to provide some analysis (or even an opinion) that would at least shed some light on how other people in the community felt about the whole thing... nothing doing though, so i've had to mull it over myself and i've come to the conclusion that my knee-jerk reaction was right...

the fundamental arguments against writing viruses for supposedly good reasons are a) there are inherent risks and social costs (unless you're able to ensure that no one ever finds out about it or encounters it) , and b) there ways to get the same results without creating a virus and thus without the problems in (a)... both of these apply in this case...

the risks are that the virus will fall into the wrong hands (either accidentally or on purpose) and affect people and as smart and trustworthy as the researchers may be, no one is above reproach (saints have been known to kill people), no one is beyond making errors... the risks remain no matter who is involved and the impact here could be dire, subverting the democratic process (even just for a single country) can a affect everyone... add to that the social costs of telling people who really have no business handling viruses let alone creating them that virus creation is a legitimate research practice... sure it might also embolden smart people to do good research too, but considering the persistent and autonomous nature of the threat that a self-replicating program poses (it can keep going and going long after anyone involved in it's creation or spread has lost interest and moved on) it really does only take a few bad apples to ruin the bunch...

that brings us to the issue of there being ways to get the same results, in this case being able to prove the same things, without creating a virus... i've already shown that this is possible in the general case and in this case in particular the researchers state quite clearly that the voting machines are general purpose computers (that makes viral susceptibility a forgone conclusion)... in fact they've made it clear that the machines run a version of windows, so there's absolutely no reason to create a virus for this platform since just about everyone knows that windows and viruses go together like peas and carrots... unless you want your new nickname to be 'captain obvious' there's no need to prove a virus is possible on this platform and so no need to create one for their security proof...

so if there was no need to create a virus, if you could demonstrate everything you needed to demonstrate with non-viral code (and you could), then the ends can not justify the means - the risks, however small they may be, remain present and the social costs are completely unmitigated... i don't want to bash the researchers too much (i do that an aweful lot) especially since there was a question (at least in my mind) about whether or not the ends might really justify the means in this particular virus-creation case (by gosh, democracy was at stake), but creating an actual virus (and by their description it was an actual virus, basically a kind of boot infector) was a wrong-headed thing to do...

how to prove 'virus-ability' without creating a virus

let's say you're a security researcher and you're trying to demonstrate some security problem that involves viruses... it's relatively easy to write your deomonstration code as a non-replicating proof of concept exploit and simply say "this could easily be attached to a virus" and leave it at that - it's perfectly true that it could be attached to a virus, any function you like can be added to a computer virus, they're just programs after all...

that's all well and good if you're dealing with a normal desktop pc or some other platform for which we already know viruses are possible, but what if you're dealing with a system where viruses are as yet unheard of like an internet connected toaster, an assembly line robot, or an electronic voting machine? it may not be enough to just assume viruses are possible on such platforms, of course, because the proof you were trying to construct for the existence/feasability of whatever threat you were trying to demonstrate won't really be much of a proof anymore... you could try proving that the system in question satisfies the requirements of a general purpose computer, after all virus infectability is inherent to the general purpose computing platform, but that's probably going to go over most people's heads...

so try this instead: first show that you can introduce your own code into the system and get the system to execute it, then show that the code you introduce can write a secondary program (like a hello world program) to the systems storage memory and execute it... at this point you've proven self-replication is possible on the system, because if your main program can write a secondary program to the system's storage memory it can also write a copy of itself there...

now, let's say you want more than just basic self-replication, lets say file infection... have your main program do one of the following: write it's secondary program overtop of an existing host program on the system, rename an existing host program to something else and then give your secondary program the name the host program used to have, or change whatever pointer the system used to locate the existing host program so that it points to your new secondary program instead... you have now demonstrated the potential for file infection and so far have still not created a virus...

but wait, there's more - what if that's still not enough (and lets be honest, messing around with a single computer system doesn't really have the impact it used to), what if you need your hypothectical virus to spread to other systems over a network (a network worm)?... this too is relatively simple, instead of having your main program write a secondary program to the local computer's storage memory, have it send the secondary program to a second system along with whatever tricks you need to get the second system to execut it... this demonstrates network spreading because your main program could have just as easily sent a copy of itself rather than a dummy program.... and if you want it to have some real visual appeal, make your hello world program print "i'm infected" instead of "hello world"...

at this point you'll have demonstrated all of the viral characteristics that would be necessary for your larger security proof without actually writing a virus, therefore making the writing of viruses for security proofs (even security proofs for computing platforms for which real viruses are unheard of) unnecessary...