what is a botnet?

a botnet is a network of bots (sometimes explained as a contraction of the word "robots")... essentially a bot is a program that, much like a RAT, allows a 3rd party to direct the affected machine to perform certain tasks; however, unlike a RAT, bots don't sit around on the affected machine waiting for a 3rd party to find and connect to them - instead they go out and connect to one or more communication points where other instances of the bot have also connected to and await instruction... in this way the 3rd party can give instructions thousands of affected computers at once...

the simplest botnet configuration is where all the bots connect to a single hub (such as an IRC chat room) where the bot master (the 3rd party controlling the bots) will give them instructions... although this is conceptually simple, it suffers from problems of scale - the more bots connected to a central communication server the harder it will be for that server to cope with all the connections...

a hierarchical network, where the bot master communicates with only a few (hundred?) bots which in turn each command a few (hundred?) more and so on, is also possible... this has the benefit of scaling better and allowing the bot master to cultivate a much larger botnet...

a third possible configuration is a peer to peer network between bots so that the bot master need only communicate with a single bot which in turn spreads the command to it's bot peers... a peer to peer configuration can help with scaling as well but the more significant strength is it's non-reliance on a central communication point that might get attacked and/or shut down...

in addition to the more sophisticated communication pathway between the machine and the remote 3rd party another difference between a bot and a RAT is that, although a bot gives control of the affected machine to a remote 3rd party, a bot would never be used for remote administration purposes... a botnet's strength is in aggregating control over huge numbers of machines and while a remote control software may be a legitimate means to perform quick and dirty remote administration of one or two machines, when you get to large numbers more formal techniques and technologies (such as group policy or active directory) become appropriate...

one way bots can get installed on a system by tricking the user into running an email or instant message attachment or other file downloaded from the internet and in this case the bot would qualify as a trojan horse at the very least... bots also are often able to spread themselves to systems by self-replication either as worms or viruses or both... in fact self-replication is often the best way to affect large numbers of systems (as we have seen time and again with worms like blaster and slammer)...

back to index

what is a RAT?

a RAT, or remote access trojan (sometimes remote administration tool) is a program that listens for and accepts connections from a remote 3rd party and carries out the commands that 3rd party gives it... essentially it's a server that provides remote control functionality...

as is traditionally the case with trojans, there are some circumstances where this functionality is legitimate or even desirable and some circumstances where it is not... it is legitimate and desirable when you are the administrator of the system with the remote control software on it and are personally using the software to administer the system remotely...it is not legitimate when you are tricked into installing it or are otherwise unaware that it is installed on your computer and unaware that someone else has control of that system (most responsible remote administration tools are made in such a way as to not be easy to install without the user's knowledge or consent)...

it is only in the circumstances where it is not legitmate or desirable that such a remote control program qualifies as a remote access trojan...

back to index

what is a backdoor?

a backdoor is simply a way of accessing something through alternative, often unwanted means...

this can come in many forms, from a bug in a program that allows illegitimate access to data when some condition is met to a piece of software specifically written to allow remote access to a computer...

backdoors are security vulnerabilities that ideally should be kept to a minimum or eliminated entirely if possible... the computer owner may actually make use of some backdoors but that is a security trade-off that should only be made when fully aware of the potential consequences...

back to index

what is spyware?

spyware is any program that reports information about you, your activities, or your system back to a 3rd party...

like adware, spyware can sometimes have legitimate uses... for example winamp can (if so configured) report usage statistics back to nullsoft... windows xp, upon encountering a crashed application will offer to send a memory dump of the application to microsoft... even your browser reports information about you back to the websites you're on so that those websites can show you data that is appropriate for you such as the contents of your online shopping cart if you happen to be on an online store's site...

as the name suggests, however, there are more sinister uses for spyware such as stealing passwords or credit card information... this type of spyware generally gets installed or reports to a 3rd party without the user's knowledge and/or permission...

spyware that spies on you without your knowledge and/or permission qualifies as a type of trojan... in fact, the term spyware is so pejorative that it is almost exclusively used to refer to those examples that also qualify as trojan horse programs...

there is a complication in the spyware landscape, however... this complication arises because sometimes the user of a computer and the owner of that computer are not the same person... some organizations use spyware to monitor what their workers are doing on the organization's computers and while the spyware qualify as a trojan in more conventional circumstances it's (arguably) not a trojan in these particular contexts because it has permission from the person/people who matter...

back to index

what is adware?

adware is any program that displays advertisements for something other than itself...

sometimes the display of such advertisements is completely benign and serves as a means of subsidizing the development of software or the provision or services... for example, older versions of the opera web browser displayed ads to users who hadn't paid for the browser in order to help pay for the cost of development of the software... users had the option of using the free version and letting the advertisements take up a certain portion of the screen or paying for the ad-free version and getting more screen real-estate with which to browse with... another example is the internet service providers that used to (and perhaps still do in some locales) provide free internet service so long as you used their custom connection software which utilized part of your screen real-estate to display ads...

while all that sounds ok, that's just the well behaved adware... sometimes 3rd party adware is bundled with software the user downloads... ideally the presence of this adware is made obvious during installation and the user given an opportunity to opt out of the installation - also ideal would be that the adware is easy to find and uninstall once on the system... however, often the presence of the adware is hidden in an EULA (End User License Agreement) that no one reads and is installed in such a way as to make it difficult for the user to find it and/or remove it...

when adware is installed in secret and/or is made difficult to find and/or remove it qualifies as a trojan horse program and it is this combination of adware and trojan that most people are talking about when they speak of adware in a malware context...

back to index

user education is working

there is a fairly prevalent opinion in security circles that user education doesn't work... no matter how much you try to teach users, they never learn...

my retort to this is generally along the lines of "ok, give me your name, address, telephone number and credit card information and i'll prove you wrong"... obviously no one is going to give me that information and that proves them wrong - users of credit cards learned not to give that information out to every tom, dick, and harry a long time ago (we know they learned it because it's not knowledge they were born with)...

but sometimes that fails to convince, so here's a personal anecdote... i was out having a meal with some people not too long ago and the conversation briefly turned to email and the woman beside me (whom i had never met before and never coached in any way) said she tends to delete anything with an attachment... she was the first and only person to mention attachments during the brief discussion of email...

we're not talking about a security person or even necessarily a computer person here either - she's a school teacher and she's adopted a behaviour that was unheard of in the general populace 10 or even 5 years ago...

people never stop learning things, and netizens learn to adapt to the threats present in the environment they inhabit - how could they not? staying safe online is a competitive advantage and successful strategies will be discovered and adopted and spread like memes through the computer user population... they don't need to know the internals of how various threats operate or why certain safe-hex behaviours work, only that they do work...

how to spot snake oil using the halting problem

i blogged previously about how the halting problem is good for separating the possible from the impossible in the malware field, but i suspect it's still a little over most people's heads... art kopp came up with the term "snake oil spotter guidelines" and it inspired me to try and distill what i said earlier into a (hopefully) simpler heuristic that anyone can use...

let's say you have a sequence of one or more bits or bytes... let's further say that it's of finite length (in practice we never deal with anything that goes on for ever) and that it is well defined (we know the exact sequence)... this might sound familiar, it might even sound like a virus signature, but i'm talking in a much more general sense here so we'll just call it a pattern...

1. any system that claims to find all instances of something that is equal to or contains such a pattern (ie. finding all instances of the character 'a' or the string "dog") does not run into difficulties with the halting problem and is not snake oil (at least not as far as that particular claim is concerned)...


2. any system that claims to find all instances of something that is not equal to or does not contain such a pattern (ie. finding all instances of a characters that aren't 'a' or all words that don't contain the substring "dog") does not run into difficulties with the halting problem and is not snake oil (as far as that claim is concerned)...


3. any system that claims to find all instances of something using the equal/not equal or contains/not contains comparison to any one of a finite list of such patterns (ie. finding all instances of the characters 'a' and 'b' or all words that don't contain the substring "dog" or "shoe") does not run into difficulties with the halting problem and is therefore not snake oil as far as that claim is concerned...


4. any system that claims to find all instances of something less trivial than what has been described so far, something that can't be represented as a well defined finite set of such patterns (viruses, for example, cannot be represented that way as there are an infinite number of possible viruses - so too with any function, since there are an infinite number of ways to implement any given function - also any class of bug or vulnerability has an infinite number of ways in which it can occur in practice), or by using a less trivial method of comparison (certain types of preprocessing, like decryption or decompression notwithstanding) generally does run into difficulties with the halting problem and therefore probably is snake oil...


5. any system that claims to prevent or avoid all instances of something must use a technique that is equally capable of finding all instances of that something and so the previous rules apply...


6. any system that only claims to find/prevent some instances of something doesn't run into difficulties with the halting problem and is therefore probably not snake oil as far as that claim is concerned...

wow, that's actually pretty big... let's condense it...

any system that claims to find all instances of something and that something is non-trivial and/or is to be found using a non-trivial comparison method will generally run into difficulties with the halting problem and therefore be snake oil...

as a corollary to the above, all real world threats and vulnerabilities wouldn't be problems if they were trivial... therefore any system that claims to find or prevent all instances of a particular kind of threat or vulnerability is snake oil unless the particular kind in question is specified narrowly enough that it applies only to a specific, well defined, finite set of items that can themselves be represented by one or more of a finite number of the above mentioned patterns... for example, all known viruses represents just such a set of items and can therefore be detected and/or prevented without running into problems with the halting problem...

the descent of rootkits

i think it's about time to get to the root of the rootkit terminology shift...

i've blogged before about what i think a rootkit is, and about how the anti-spyware coalition's definition is basically in line with my own...

and yet somehow the definition currently in use is all about hiding processes and/or activities from the user rather than about root/administrative privileges...

as i observed before; f-secure, despite acknowledging that the original unix meaning was basically in line with the one i use in this little blurb:

The term rootkit is very old and is dated back to the days when UNIX ruled the world. Rootkits for the UNIX operating system were typically used to elevate the privileges of a user to the root level (=administrator). This explains the name of this category of tools.

still insists on using the new hiding-related definition...

but my first clue about where this new definition came from was in mark russinovich's blog entry where he gives his definition:

Software that hides itself or other objects, such as files, processes, and Registry keys, from view of standard diagnostic, administrative, and security software.

which he says he derived from what the rootkit developer community was using as a definition and which happens to basically mirror the definition proposed by greg hoglund, founder of rootkit.com (a hub of the aforementioned developer community) and author of a book on these so-called rootkits (not that registering a domain and/or writing a book actually makes anyone a credible authority, but for the sake of argument lets say he is one), which states:

A rootkit is a tool that is designed to hide itself and other processes, data, and/or activity on a system.

a rootkit developer community? well, a community of developers of cloaking technology at any rate... but lets think about this for a sec... by and large, these developers are not going to be a malicious bunch (there are far more good people in the world than there are bad) so when they look at rootkits, even the original unix-style rootkits, they aren't going to really be all that interested in the more blatantly malware type features - the thing that's going to interest them is the cloaking because it has applications outside of malware...

it has been suggested that terminology changes with frequent misuse and that is most likely what happened here... the developer community in question, lacking any significant influence from malware experts (since malware issues were outside the scope of their interests, and because malware expertise is a lot harder to come by than you might think), used and reused the term rootkit (since rootkits represented examples of the kinds of sophisticated stealth techniques they were interested in) so much outside of it's original meaning that they gave it a new meaning...

so what? you might well think that language changes in just this way so there's nothing wrong here, but consider this:

• technical jargon does not evolve the same way that conversational language does... imagine if people started using the term 'telescope' to refer to something completely different...
  
• hoglund's definition describes what is more properly known as stealth in the malware field... the concept of stealth has enjoyed wide use in the malware field for at least the past 20 years (back in 1986, the brain virus wasn't just the first pc virus in the wild, it was the first stealth virus) and has been applied to virtually all forms of malware, not just rootkits
• stealth is actually a more natural and intuitive label for what hoglund's definition describes; so much so that the term is creeping back into the vocabulary of the rootkit community at rootkit.com to cover new types of cloaking that 'rootkit' is no longer felt to encompass
• under hoglund's definition, the term 'rootkit' has no etymological basis - that is the word doesn't appear to come from anywhere or be rooted in any underlying details... by comparison, a collection of programs (-> a collection of software tools -> a toolkit -> a kit) that aids in gaining or maintaining root/administator (administrator is called 'root' in unix) access is fairly clear about where the term 'rootkit' comes from

while upcoming concepts like 'stealth by design' indicate that the current terminological misstep may be in the process of correcting itself, there will be purists who will resist the change in terminology on the basis that the proposed new definition of rootkit is not what a rootkit was supposed to be... they'll simply have to be reminded that their rootkit definition was not the original one either and if the correction does take place it will simply be a reversion to the original state of things...

feedback

this post is a little towards the administrivia side but it's been something i've been thinking about for a while...

you'll probably notice that there is no way to post comments about my blog articles - that's intentional and there are a couple of good reasons for it...

the first is that by and large most of my posts here are rants - they're posted in order to get something off my chest, not necessarily strike up a discussion...

the second, perhaps the more important, is that i don't feel like providing yet another malware forum, much less have to maintain yet another malware forum (i'm already the moderator on a couple of malware discussion forums and frankly, i don't need to add to that list)...

and lastly, i just like having the last word, and rather that fiddling around with comments or arguing 'til i'm blue in the face, i just leave comments off... (i also don't have to deal with comment spam this way)

that said, i suspect people would find my blog more fulfilling if they had some means of interacting with me and maybe even changing my mind or holding me accountable for whatever errors they think i've made... i still don't want to create any new forum for discussion so i've decided to do something a little unorthodox - i'm going to direct people to existing unmoderated (so that there's no chance of me manipulating conversations) forums in the form of 2 usenet newsgroups - alt.comp.virus and alt.comp.anti-virus... i've also created a disposable email address specifically for feedback so you can email me here [edit: mailto link removed]...

[edit: adding new contact feature]
ok, i was using sneakemail.com to provide a disposable email address that i could use on this site, but mailnull.com has an even better service... the idea was always to prevent spammers from getting my real email address by having their bots parse my blog looking for anything that looked like an email address... the disposable email address allowed me to be contacted without revealing my real email address but the spammers could still send email to that address... mailnull.com offers a web contact form to go along with their disposable email service and that effectively removes all email addresses from the web page - so now you can contact me here...

[jan 1, 2007 - edit: this is probably the most changed page on the whole blog]
guess i'm growing soft in my old age, i've just enabled comments... so much for all my arguments against them...

what is DRM?

digital rights malware (or digital rights management software if you prefer) is any program bundled with media (text, graphics, audio, video, or some combination thereof) that takes some measure of control over the user's electronic device(s) in order to limit what the user can do with the media, often in contradiction to some extent with what applicable laws say the user should be allowed to do with it...

the user is often unaware of the presence of the digital rights malware his/her media purchase has been crippled with or how it invariably works against his/her interests, so it therefore qualifies as a kind of trojan...

in recent months there has been a trend to label any form of digital rights malware that uses stealth to hide itself (and in order to be effective against any user with half a brain they have to use stealth) as a rootkit... this is part of a larger and rather misguided trend to call anything that uses stealth a rootkit... while DRM is malware, it is not necessarily a rootkit...

there is an older trend (and some well known examples of success) of trying to get protection of digital rights malware enshrined in the law... this moves the creation and maintenance of copyright policy out of the hands of the government and into the hands of various corporate interests and has sometimes been called paracopyright... in places where this has taken place many of those corporate interests have proven themselves uninterested in the user's rights many times over...

(see my previous posting on digital rights malware here)

back to index

SANS - strike 2

i posted previously about SANS hosting and distributing malware and what i thought of it... well here's strike 2 against them...

apparently now they're asking the general public to send them samples of some worm...

now, under my ideals of responsible handling of self-replicating materials i'm willing to accept that some people might actually feel like there's a good reason to trust them - after all, it's SANS...

but think about it for a minute... they have to resort to asking the general public for a sample? that tells me that either no one in the anti-virus research community or industry trusts them enough to give them a sample, or the people at SANS involved in this aren't even bothering to develop the contacts needed to get these types of materials through the right channels...

either way, it isn't good...

this has got to stop

ok, so it was bad enough when sony's digital rights malware got labelled a rootkit, at least it really was malware... but now anti-virus products and other legitimate programs are being called rootkits too...

this is basically a witch-hunt, everything that hides anything is getting called a rootkit and it clearly isn't serving the public's interests... at what point in the process of calling legitimate apps and even anti-virus products rootkits does one wake up and realized they've made a tremendous error? at what point does one own up to that mistake and admit it? before or after you become a media darling?

cloaking of any kind is bad and microsoft agrees? windows cloaks things... "Hidden files and folders", "Hide extensions of known file types", "Hide protected operating system files (Recommended)"... and don't get me started on "NeverShowExt"

there are some circumstances where hiding things is clearly bad, such as hiding them from the administrator... however hiding things from ordinary users can reduce confusion and the potential for user initiated disasters... hiding things that can help to detect the presence of malware from that malware can reduce the malware's viability in the real world... so long as the administrator has the ability to disable beneficial cloaking there should be no problem...

what is stealth?

stealth is a property held by instances of malware that employ stealth techniques... stealth techniques are any techniques which serve to hide something (usually malware) from something else (usually the user or security software employed by the user)...

in malware, stealth is not an attack in and of itself but rather it is an adaptive strategy applied to other attack techniques in order to increase their likelihood of success... by keeping evidence of the attack hidden, the window of opportunity for the attack to succeed remains open longer and therefore the number of opportunities encountered that could lead to success tends to increase...

virtually all classes of malware have employed stealth techniques at one time or another, however not all instances of malware employ stealth techniques... further, stealth techniques are not exclusively the domain of malware - stealth has been employed in legitimate applications too... in fact there are some cases where stealth is used to hide information used by anti-malware applications from the very malware they're trying to protect against...

back to index

what is a rootkit?

a rootkit is a collection of one or more programs that aid in gaining and/or regaining (sometimes expressed as maintaining) root/administrative access on a system....

by gaining access i mean that they provide an attacker with credentials for a user with administrative privileges or a user whose privileges can be escalated (by use of some additional exploit) to administrative priviledges... usually this is performed with network sniffing from other compromized machines or some other password stealing technique...

by regaining access i mean that they provide an attacker with an easy means of re-entering the system with their administrative priviledges at a later date... usually this is done with a backdoor of some kind...

rootkits originated in the unix domain but have since been brought into the windows fold with an unfortunate twist - many in the industry have taken to redefining rootkits under windows to be basically anything that hides files, registry keys, alternate datastreams, etc... they ignore the concept of root/administrative privilege entirely (that's where the root in rootkit comes from - root is the administrative user account under unix/linux), instead focusing exclusively on what might otherwise be called stealth...

stealth is not an attack in it's own right but rather it is a technique for keeping the window of opportunity open longer, thereby improving the likelihood of success of the actual attack... virtually all classes of malware have employed stealth techniques (as they used to be called before the year 2000) at some point or another, not just rootkits - rootkits are not special in that regard... the application of stealth techniques helps to hide the programs that comprise the rootkit, allowing the rootkit more time to steal passwords and other sensitive information, and allowing the attacker more time to use the compromized system...

stealth became such an important part of rootkits (especially under unix where security-aware admins monitor system integrity carefully) that the stealth techniques themselves became the means by which the presence of a rootkit could be detected... perfect stealth, it turns out, is hard if not impossible to acheive and by using multiple techniques to examine system resources and comparing the results it is often possible to detect when something is being actively hidden from sight... unfortunately this a generic detection technique and as such is prone to alert on anything that hides things whether they're rootkits or something else, so the choice to categorize all things detected this way as rootkits is curious and a little troubling... and considering there are also software products out there that hide things in order to protect them from malware (instead of being malware) it can lead to a great deal of fear, uncertainty, and doubt among users...

in short - stealth isn't what makes a rootkit a rootkit, it's what makes a rootkit a successful rootkit... that's why virtually all of them use it...

(see these two usenet articles for additional analysis of what a rootkit is, and thanks to roger wilco for the debate)

back to index

what is a functional definition?

in the malware field the ideal kind of definition for a class of malware is the functional definition... essentially it is a definition that defines the class of things by what function all things in that class must perform...

for example a web browser must be able to browse the web, and anything that can't browse the web cannot be a web browser...

the reason this is the ideal kind of definition in the malware field is because it depends only on things that can be determined by examining a malware sample itself... this makes it the most objective type of definition...

by contrast some definitions depend on speculation about the intent of the malware author or about the perceptions of the user... such dependencies make for very subjective definitions, and such subjectivity leads to disagreements over whether a particular peice of malware actually belongs to the subjectively defined malware class in question...

back to index

what is a trojan?

a trojan horse program is a program which the user believes performs good (or at least benign) function but which also or instead performs a function the user would not approve of if s/he knew about it...

there are those who think trojan horse programs are synonymous with back doors, however that is only one of the many different types of trojans known...

the most striking thing about this is that it is not a functional definition... we cannot determine if program X belongs in the trojan horse class just by examining it, we must also look at how it gets presented to the user and make guesses as to how an average user might reasonably interpret that presentation...

for example, format.com (the utility used to format disks) is certainly not a bad program - if you need to format a disk then this is the program you want to use... however, if someone were to rename it to best-blowjob-ever.com (an example of social engineering) then someone else could be in for a nasty surprise when they tried to run it...

this may seem like nothing more than a mental exercise so far, but now imagine you were going to write an anti-trojan program to help protect people from trojans - how could your product alarm on best-blowjob-ever.com and not on format.com when their contents are identical? in general it can't be done and so deciding whether or not to detect program X as a trojan becomes a balancing act... one has to try to decide whether it's more important to warn people of the potential trojan or to not create fear among those who happen to have a legitimate program that gets maliciously misused in some circumstances...

these kinds of problems innevitably stymie efforts to help protect people from malware and is why non-functional definitions are such a bad thing... unfortunately, in the case of trojans, that's the kind of definition we're stuck with...

back to index

what is social engineering?

social engineering is the process by which an attacker exploits the social needs and/or desires of people and their behaviours in response to those needs and/or desires in order to engineer an outcome that is favourable to him/her...

basically it's tricking people into doing what you want them to do... a perfect example of this is the vbs/loveletter email worm... it exploited people's need to feel wanted and loved in order to get them to execute the worm... by trying to open what they thought was a message from a secret admirer, they would inadvertently execute the worm which would then send it's false promise of love to others...

this is used a great deal in malware - so much so that these days a piece of malware's success in the wild could be considered to depend more on how good it's author is at social engineering than on how good it's author is at programming...

back to index

what is malware?

malware is an umbrella term for all bad or malicious software... this includes viruses, worms, trojans, rootkits, logic bombs, keyloggers, backdoors, spyware, adware, etc...

it should be noted that for a long time (and to a large extent, even now) the public at large have used the term 'virus' as the umbrella term for all such software, largely out of ignorance of the field...

more recently there has been a push by certain commercial interests to repurpose the term 'spyware' as the umbrella term for all such software - in part because increasingly on the internet spyware is taking on the connotation of being anything we don't like/want on our computers... while this is very reminiscent of trojan (which is itself an umbrella classification), repurposing an existing term to encompass all bad software based on the whims of the uninformed public is absurd and will eventually be made obsolete by the very whims those commercial interests are chasing...

back to index

what is infection?

infection is the process or state whereby a viral program attaches itself to a host program in such a way that when an attempt is made to run/execute/interpret the host program the viral program can be run/executed/interpreted in addition to or instead of the host program...

this attachment can be in the form of inserting the viral program in the host program, inserting the host program in the viral program, replacing the host program with the viral program, placing/naming the viral program in such a way that the operating environment finds/calls the viral program before the host program, inserting a call or reference to the viral program in the host program, linking the viral and host programs through manipulation of filesystem structures, etc...

many people today use the term 'infect' to refer to putting any kind of malware into something else (such as 'infecting' audio CD's with DRM)... this is a product of the public's high level of awareness of viruses and viral concepts compared to other forms of malware (viruses have been in the wild and in the public eye for 20 years or more now) and not a correct usage of the technical term...

back to index

what is a worm?

a worm is a self-replicating program that is able to make (possibly evolved) copies of itself that are not attached to (via infection) other host programs...

that is not to say that worms can't infect host programs, there are already many examples of virus/worm hybrids that are able to self-replicate using both strategies - later variants of klez, for example... there are also examples of virus/worm hybrids that must infect a host program in order to self-replicate (like w32/ska, which needs to infect wsock32.dll in order to email itself*)...

also since it must self-replicate, a worm meets the requirements of the mathematical definition of virus and can therefore be thought of a kind of virus, but only in more academic/scientific contexts...

while there are schools of thought that would include such further constraints as being able to spread over a network or even being network-aware, these constraints are arbitrary and in some cases just wrongheaded... for example - a program that copies itself to all logical drives provided by the operating system is actually still able to spread over implicit networks like sneakernet, as well as being able to spread over more conventional windows networks in the presence of mapped drives... the requirement for network-awareness, on the other hand, is actually an attempt to narrow the network spreading constraint by introducing intent into the equation (network-awareness becomes an indicator of intent to spread over networks and thereby weed out the supposed accidental network spreading in the previous example) while completely ignoring the fact that intent is an entirely subjective quantity (especially when judging it from code) and causes the definition to no longer be functional for no apparent reason or benefit...

(* thanks to peter szor's book for reminding me of that)
back to index

what is a virus?

there are 2 answers to this question, depending on whether you're using the natural language definition or the mathematical definition used in logical proofs...

natural language definition
a virus is self-replicating program that attaches a (possibly evolved) copy of itself to other (host) programs in such a way that when an attempt is made to run the host program a call may be made to run the copy of the virus instead of or as well as the original host program...

the attachment mentioned above is commonly referred to as infection... usually it infers that a copy of the virus is actually placed within the host, however this is not always the case... the only real requirements for the attachment are spelled out above...

mathematical definition
the mathematical definition in it's most simplistic natural language form is - a virus is a self-replicating program...

this may seem a little odd that no mention of infection is made at all, but for infection to occur you need to have the concept of separate and distinguishable programs and that doesn't exist in the context in which the mathematical definition is used... it applies to the turing machine model of computation and a turing machine makes no distinction between different sets of symbols on it's tape... without logical partitions between different sets of symbols there can be no separate programs and therefore no specific host program to infect... at most the definition specifies that any offspring of the virus must not overlap the original instance of the virus (or in other words it must not overwrite the original virus in part or in full)...

(see section 3 of this paper for a more precise retelling of the formal virus definition)

back to index

what is a program?

this is going to be a non-obvious answer - a program is a collection of instructions meant to be executed or interpreted by the computer for the purpose of carrying out a task...

to that end - *.exe files are programs, but so are the macros in word/excel/powerpoint documents... so are bootsectors... so are batch files... so are the javascripts embedded in web pages... so are windows meta files (*.wmf)... so are a whole host of other things that the average person would probably not have considered a program...

so many of the things are programs, in fact, that it's easier to just say everything other than a few well known exceptions are programs and therefore everything except those few well known exceptions are potential threats... in fact, even those few well known exceptions could be also be threats given the right nefarious modifications to a standard operating environment...

back to index

what is it?

if there's one thing that ticks me off more than anything else it would have to be terminology misuse/abuse... technological jargon terms generally have fairly precise meanings and their misuse/abuse twists their meaning until they become useless...

how can i address this little pet peeve of mine? quite simple, really... come up with a glossary of terms with detailed explanations and then point people to it when wander too far astray...

so for the next i-don't-know-how-long i'm going to be defining things and i guess this post is as good a place as any to index them...

the 'behaviour monitor' fairytale

y'know, i'm starting to get a little sick and tired of the recent resurgence of

anti-virus software looks for suspicious behaviour so why didn't/couldn't it stop X

and

anti-virus software should look for suspicious behaviour so that it can protect us against Y

it's not a new idea - not by a long shot... it's more than 10 years old and used to be known as behaviour blocking...

way back in the day there were some programs that did this sort of thing (notably thunderbyte anti-virus) but the idea lost favour for some very good reasons...

the first is that if you allow the malware to run (which you need to do in order to take note of it's behaviour) then the malware can simply shut down the behaviour monitor and go on about it's merry malware way without having to worry about raising any alarms... this wasn't just a theoretical possibility, it happened... then it happened again, and again and again... even today, despite the lack of widespread use of this technique, viruses and worms and trojans and all sorts of other malware routinely are programmed to kill large lists of security-related processes... clearly, once the malware is running on the same cpu as your security software the window of opportunity for that security software to reliably stop the malware is closed...

another very good reason the idea fell out of favour is the false alarm problem... the software would have to decide whether or not to raise an alarm based on the number and severity of suspicious actions a suspect program takes - the lower the threshold is set the more sensitive it is to suspicious actions and the more likely it is to raise an alarm on something that is completely safe - the higher the threshold is set the less sensitive it is to suspicious actions and the more likely it is to let something bad slip through... letting bad things through is bad enough, but raising alarms on safe programs when the user has basically no real way to determine if the behaviour monitor's suspicions are warranted or not wastes the user's time on needless research and recovery - not to mention that most user's first instinct when faced with an alarm from their security software is something closer to panic than to reasoned analysis...

there are still a few products out there that use behaviour monitoring, but in general they're obscure products... the problem of being shut down by malware is mitigated by that obscurity (security by obscurity is no security at all, however) as the malware writers won't think to include those products in the large lists of processes to kill... the problem of false alarms is dealt with by - well, perhaps there's a good reason they remain obscure products (perhaps the problem isn't dealt with all that well at all)...

although behaviour monitoring does have some strength in areas where contemporary scanning technology is weak (new malware), it's weaknesses more than cancel out that strength...

(and yes, i'm fully aware that one way to deal with the problem of being shut down by the malware is to run the malware in a virtual environment instead of on the physical machine, but then we're no longer talking about simple behaviour monitoring - that's sandbox technology)

digital rights malware

you might think that there's a legitimate need for DRM... you might think that DRM gives users options and flexibility... you might think that the Sony BMG DRM rootkit fiasco was an isolated incident that would never happen again...

you'd be wrong...

digital rights management, or more accurately digital rights malware is a technology whereby people who provide the user with content exercise what they feel is their right to take some measure of control over the user's electronic equipment...

it doesn't prevent copying (it can't prevent copying), at best it prevents using copies on machines that the content providers (or DRM providers acting as agents of the content providers) don't think the user should be allowed to use the copies on... i say at best because it totally ignores the concept of the darknet which effectively renders copy controls useless as soon as one person finds a way around the controls...

DRM takes control of the user's equipment - not to the same degree (usually) as a remote access trojan, but it's still taking some control and it is doing so without the authorization of the user... even under those circumstances where the full extent of the DRM's behaviour is revealed in an End User License Agreement (EULA), the EULA will go unread (as they all do) because EULA's are so full of legalese that the ordinary person can't actually understand them...

DRM can't work without treating the user as an opponent, it's entire reason for being is to prevent the user from doing things that the user wants to do... there can be no legitimate need to install software on user-owned computers that acts against the user's interests unless you condone a copyright police state...

copyright should be protected by law, not technology, but the content providers don't trust the law to do that so they turn to DRM in order to gain more control... then they lobby for anti-circumvention laws to protect their DRM, effectively legitimizing the control they're grabbing in the eyes of the law and shifting the authority to make copyright policy away from the government and towards content providers (with all their vested interests)... but of course they don't trust the laws that protect DRM anymore than they do the laws that protect copyright so they employ additional offensive technology to protect their DRM as happened in the Sony BMG debacle, and as will continue to happen (though with better PR) and possibly even escalate... it has to keep happening or the content providers have to start relying solely on the law to provide protection, thereby giving up the control they so obviously desire...

ultimately what it comes down to is control... DRM is meant to usurp the user's (and, when combined with anti-circumvention laws, the government's) control and therefore is much deserving of the malware classification (even if anti-virus/anti-spyware/anti-malware vendors can't or won't deal with that particular class of malware (yet)...

the halting problem - why you should care

the halting problem is very technical and i'm certainly not going to do the technical aspects of it any justice here (and the technically minded really aren't the audience i'm writing this for anyways)... the short version is that the halting problem tells us what is not possible in the computing world...

the basic idea goes like this: there is no set of steps a person or computer can follow that will always determine if an arbitrary program will halt (terminate/exit/stop running)...since following steps (instructions) is all a computer can do, this is significant for computers and computer software...

the reason this is interesting and useful to us is that we can apply it to other things - by that i mean that if we can show that doing X is reducible to the halting problem then we've effectively proven that it is impossible to do X...

now, lets follow a simple progression... creating a set of steps that will always determine if an arbitrary program performs function Y is reducible to the halting problem - all you have to do is say that function Y is a halt function and you'll see it's trivially true... there's nothing special about code that causes a program to exit that would make it difficult to find, the problem is determining if it will ever get executed...

creating a set of steps that will always determine if an arbitrary program is a virus is redcuible to the halting problem.... to be a virus the program has to perform the function of self-replication and since you can't always determine (by following a set of steps) if an arbitrary program performs that function, therefore you can't always determine if that program is a virus...

creating a set of steps that will always determin if an arbitrary program performs any other virus-like functions is reducible to the halting problem... i'm sure by now you can guess why...

this probably looks pretty bad... it seems like we can't tell very much at all about arbitrary programs - and not only is that absolutely true, that's also the point... that's why the halting problem is important; it shows us what can't be done so that we can separate the impossible claims from the possible ones, so that we can understand what is preventing anti-virus developers from finding all possible viruses, and so that when someone comes along and says "well why can't it just look at the code to find out what it does" we can know why that won't work... knowing what isn't possible is probably the best tool there is when it comes to weeding out the hype and identifying snake-oil in the anti-virus field...

SANS is distributing malware? wtf?

no, i'm not going to point you towards the URL to see that their malware analysis quiz includes real malware... i'm not going to raise the search profile of malware that is apparently still effective (by virtue of how SANS acquired it in the first place)...

i can, however, post a url to a featured quiz answer sheet for one of the previous quizes in order to illustrate the nature of some of the malware SANS is making available to the public...

thank you SANS for providing malware to the masses and for showing me what you're really made of... clearly you folks belong to the wrong-headed full-disclosure for everything mindset... maybe you should take some time out of your busy schedules and examine what the classical benefits are for full disclosure and whether those benefits are achievable in the malware field...

what's that so-called real story again?

bruce schneier spins a yarn quite well in his recent article on the sony DRM scandal so i'm not goint to bother making any kind of 'story' here...

read it... see if you can see what i see...

no, no, not the terminology misuse (that his own readers picked up on - in the industry it's that pesky cloaking business that makes something a rootkit, regardless of how bizarre that sounds)... no, he blames anti-virus companies for not detecting the rootkit sooner...

hello?!?! where was bruce almighty during that period, hmm?? where was his company counterpane and their managed security solution? didn't they detect anything??? we're talking managed security here, with actual people at the helm rather than the automatons that anti-virus software represents... i don't recall bruce raising the initial alarm, do you?

anti-virus software detects what it knows... how does it get to know something? by the people who make it being given samples or at least pointed in the right general direction as f-secure was...

how exactly were they going to get that information sooner than they did? ('chance' is the only way i can see that happening) and without that how were they supposed to detect it? are anti-virus companies supposed to sift through and analyze every line of code on the planet, and if so are we to believe audio CDs should have been high on their priority list?

and then, to go on and make the disingenious statement that that kind of protection is exactly what we pay anti-virus companies for when he knows damn well (writes about it, talks about it, made a business model out of it) that real security isn't as simple as installing software and expecting it to protect you, that it's a process, that it requires real people making intelligent and informed security decisions - i'm sure that made for good copy but it's still hipocrisy... people protect computers, the software is just a tool to help them do the job... and of course no security, no matter how good, is perfect...

anti-virus software cannot protect you from everything all the time... many of them have no anti-rootkit technology yet, and detection of phoning home is generally relegated to the software firewalls...

bruce appears to be too far removed from the anti-virus community (note, i'm not specifying the industry) to get it... i've been part of the community for well over a decade and the only person i know who even mentions his name is me... i suspect the security guru simply considers viruses to be a small niche in the overall security landscape, and that may be true but the devil's in the details and those are something he isn't displaying a firm grasp of here...

i'm no anti-virus apologist here, though... he did get one thing right, any av company that wasn't all over this when the new broke deserves a swift boot in the ass... f-secure shouldn't have been the only av company denouncing sony's move from the get-go...

what the Common Malware Enumeration really is

i was not the least bit impressed by what i read in the comments to Schneier on Security: Computer Malware to Have Uniform Names... clearly people don't understand what the CME is or what it will be able to do...

first and foremost it is NOT a new naming scheme, it won't replace existing names or displace existing naming conventions... anti-virus companies will continue to name viruses in exactly the same way as they have been - the Common Malware Enumeration won't change that... at best the CME will provide a well coordinated alias for malware of significant interest...

the CME will not solve the naming problem... the naming problem is a byproduct of the commercial anti-virus environment - many competing organizations working in parallel on their own products necessitates that they come up with names themselves in order to get signatures to their customers as quickly as possible... waiting for some centralized body to give the malware a standard name means that they'd be leaving their customers exposed to the threat without protection for longer (because of the "deconfliction" process) which would ultimately hurt their bottom-line...

the CME isn't necessarily going to improve the situation for users... not only are average users not going to be aware of what the CME is or what the CME number for a particular peice of malware can be used for, but it will likely have a similar effect on the anti-virus community that project vgrep had - it's presence will make naming consistency seem less important... it won't actually be less important, CME's will be numbers and thus will be next to unusable by real people except as an index to use when looking something up - names will still be used when discussing things or calling up tech support, etc... names are what people actually remember, not numbers, and with less motivation to be consistent with other organizations when it comes to naming the naming problem is likely to get worse instead of better...

this won't lead to better protection, it won't even guarantee less confusion... it'll be a big help to those of us who know what's what (and hopefully it won't go in the brain-dead direction project vgrep did by requiring registration in order to do lookups) but that's about it...

the importance of good definitions

Techdirt has an article on the recent attempts by a group of organizations to come up with an agreed upon set of definitions for spyware and adware... predictably, Techdirt gets it all horribly, horribly wrong...

the author feels that what the software does or doesn't do is immaterial - that any unwanted application that got on one's machine by unknown means should be classified as spyware... he's not the only one who feels that way but there's a BIG problem with this line of reasoning...

the problem is that classifying instances of software on the basis of how they make some nebulous real world group of users feel (which is essentially what the author's position boils down to) is ridiculously difficult on a number of levels... not only will countless millions be spent on navel-gazing exercises trying to divine whether a particular instance of software in a particular software bundle is going to be unwanted and unnoticed at install time by some fictional average computer user or one if his/her 3.2 kids, but countless millions more will be spent defending against a deluge of specious lawsuits on the grounds that each classification was arbitrary and prejudicial - ultimately leading to a system where the courts, rather than the industry decide which program is spyware and which isn't..

we're computer scientists, not mind readers - we don't deal with this eye of the beholder crap unless we absolutely have to - and in this case we don't have to... we already have an umbrella term for all bad software - it's "malware"... if we're going to classify software for anti-whatever purposes we need to do it based on functional definitions (definitions based on what functions the software performs rather than definitions based on guessing how users will react to it)... we already have one malware classification saddled with an eye of the beholder definition, it's known as the "trojan", and that non-functional catch-all definition has been the bane of anti-trojan detection for years and is probably the reason we've had to make so many other classifications because it's proven totally unworkable as a classification that people can agree upon... classification based on eye of the beholder type criteria excludes widespread agreement by definition...

functional definitions, on the other hand, are much more reasonable... no guessing is involved and legal defense is practically a non-issue - define something based on it's function and it becomes much more feasible to demonstrate that a particular thing belongs or doesn't belong in that class...

on reading the actual document that the group of organizations (the anti-spyware coalition) came up with i think that for the most part the definitions are reasonable but a little on the wordy side... adware, for example could be much more simply defined as any software that advertizes a product or service other than itself... likewise spyware can be defined as any software that surreptitiously collects information from the user's system and sends it back to a remote 3rd party...

they did miss the mark on rootkits again, but the most notable problem is their adoption of spyware as an umbrella term for just about all bad software... they justify this by saying that the public at large is calling it that but this is foolish; 2 years ago the public at large was calling all bad software viruses, 2 years in the future they'll be using yet another term... how will this system cope with that? better to ignore the foibles of the unwashed masses and simply strive for internal consistency... trying to accomodate terminology misuse by people who don't know what they're talking about will never work because the people who don't know what they're talking about will not be consistent over time - leaving those of us who do know what we're talking about having to guess what they're talking about regardless of how accomodating we try to be...

EDIT (07/19/2005): i retract what i said about their definition of rootkits - i don't know what i was looking at before but now it looks fine... turning spyware into an umbrella term is still bad though...

the end of anti-adware/spyware software

it seems like only yesterday that microsoft stepped into the anti-adware/spyware business and now it's probably going to collapse...

why? well, the thing about adware and spyware in the past was, despite being a pain in the ass to remove they were relatively easy to detect... stand-alone programs or dlls that are discrete and easily removed, that use various registry or other startup tricks to make sure the the adware/spyware runs also gives away their location...

unfortunately, just as our cyber-innocence was lost 20 some odd years ago by the advent of computer viruses, some of it's final vestiges that managed to stick around are again under siege by file infecting adware...

you're probably wondering why i would take such an alarmist stance on this, since i rarely do so... the reason is simple - existing anti-adware/spyware technologies simply can't cope with file infection, it is in no way comparable to what those products were doing before, the only thing that can deal with file infection right now is anti-virus technology... so we're back in the position of needing the anti-virus industry to provide all-in-one 'solutions' again and the anti-whatever-else industries will be left in the dust because AV technology is neither cheap nor easy to develop and the AV industry has an incredible headstart...

this is actually really sad for the people involved... we had all these new types of threats and whole new industries spring up to try and deal with them, and then someone goes and adds file infection to them and it all falls down... the only 2 ways this won't happen is if file infection doesn't catch on as a big trend in adware/spyware, or if the anti-virus industry sits on their hands and (intentionally or otherwise) gives the anti-adware/spyware guys a chance to catch up...

of course, you could (quite correctly) argue that they should have seen file infecting adware/spyware coming and developed their products with that in mind, but that doesn't make things any less sad for the employees (who generally don't have a huge say in the architecture of the product) of those companies...

[edited to fix totally borked link - thanks for pointing that out nick]

HP and wishful thinking

so, if you read "HP Labs - Virus-safe computing : Experimental solution makes security a cinch" you will no doubt get the impression that HP has come up with the virus solution in the form reducing priviledges for applications...

if only things were so easy...

the first mistake seems to be blaming the operating system... they make a good argument for it but it ignores the decades old result that all general purpose computers are susceptible to virus infection... it's not the operating system that decides whether a computer is a general purpose computer or not, that's only part of it - the hardware plays a part too... take bootsector infectors, for example: they're operating system agnostic, they run straight off the bios (or even lower level hardware interfaces) without intervention from any operating system... clearly, making changes to the operating system alone will not stop a computer from being infectable...

let's humour them for a moment though... the premise of the idea seems to involve preventing applications from being able to access that which they have no need to access - one of the examples they use is that Solitaire should not be able to search your desktop to perform it's intended function... they hope to apply the principle of least priviledges (or principle of least authority, depending on who's talking - it's basically the same thing) to individual programs, which is a novel departure from normal operating system security that normally only defines priviledges for principals (users, local machine account, etc)...

let's consider this carefully - there are thousands, possibly hundreds of thousands of programs on today's computers (most of which the user isn't even aware of), how are we to define what priviledges each and every one of those programs is supposed to have? there are 4 options:

1. the computer could figure it out by itself by examining the programs
2. the user could define them all at the outset
3. the user could answer yes/no to a variety of pop-up questions as new applications are run and the system needs to know what kinds of priviledges the new applications should have
4. some authority (like HP perhaps?) could define the proper priviledges for all applications everywhere in a central database that and that information would then need to be communicated to systems that need it

(1) is not really an option... it runs afoul of a little thing called the halting problem (if we could solve the halting problem we could have perfect virus scanners and this blog probably wouldn't exist)... not only is it not generally possible for a program to determine what another program does by looking at the code, it would require that we examine the program in it's uninfected state first and that's not generally an option when we download infected materials...

if you think (2) seems like it would be an unreasonable burden on users you wouldn't be alone... in fact both (2) and (3) ask the user to decide what programs should be allowed to do and the user is almost certain to make mistakes - the more the user has to decide, the more mistakes are likely to be made, and those mistakes can lead to lost functionality ('i didn't know the program needed to do that'), more priviledges (and therefore more opportunity to spread infections) than necessary, or both... there could be thousands of decisions to make and users are just not likely to do that at the outset... the pop-up questions (now familiar from such things as software firewalls) require less from the user at any one given moment, but that doesn't address the problem of knowing the right answer to the popped up question... it's a problem in software firewalls too, but at least in software firewalls all you need to do is figure out if the application is supposed to use the network - this system would require much more indepth knowledge of each application...

and that leaves (4)... maybe a central authority could define the appropriate priviledges for all known software in existence, but i doubt it... and even if they could produce entries for all known software, such a huge database would invariably have the problem that all large databases have - incorrect data... not to mention that this would boil down to a central software registry such that people would only use the software found in the authority's database (for security reasons of course) which winds up being no different than the proposed system where people only use software that's been digitally signed and certified by a similar central authority...

and besides all that, your application priviledge system would then need a reliable, unspoofable means of identifying the program (filenames aren't enough, i can change filenames to whatever i like) - and not just the current version of the program but all versions of the program, for all programs... and it would have to recognize that some versions of a program would need different priviledges than other versions of the same program (due to differences in feature sets)...

i'm certain the folks at HP are not the first to think of defining priviledges on a per program, rather than per user basis... why weren't operating systems designed that way? it seems to me that the answer is obvious, because it's an unworkable system...

the above mentioned article states rather plainly that they want all the security without losing any of the features of existing software - but the features create complexity and, to quote bruce schneier, "complexity is the worst enemy of security"...

ultimately, reduced priviledges doesn't actually stop virus infection - what happens when a program that requires a great deal of priviledges becomes infected? it spreads the virus far and wide... reduced priviledges can't do any more on a per program basis than it can on a per user basis to stop viruses - that is, all it can really do is make the path of infection more convoluted until it gets to someone/something with lots of priviledges - in other words, all it can do is slow the viruses down...

the way i see it, that article is either a very poor representation of what the researchers at HP are really working on, or the researchers at HP have 'jumped the shark'...

microsoft antivirus: the next generation

by now you've probably heard that microsoft plans to get into the anti-virus industry (again) and has already entered the anti-spyware industry... they apparently are planning to release a complete security package for a fee (see Techdirt)...

now, Techdirt makes an interesting argument for why giving away the security package might be problematic for microsoft - that they might get accused of anti-trust violations with regard to the desktop security industry...

so it would seem that they can't not charge money for their product - but here's a different angle... a big part of the problem that their product will be addressing is the insecurity of their other products... the argument has been made that anti-virus companies are the ones behind the viruses and it's an easy argument to debunk (the industry is very competitive and the companies would use that information against their competitors if it were true), but when it comes to security exploits microsoft IS behind many of the vulnerabilities being exploited... they're basically charging you to protect you from the threats posed by their other software - which sounds an aweful lot like a protection racket to me...

worse still, however, is that with their complete security package they would have less motivation to actually fix the security problems in their other software... they could say that the threat posed by vulnerability X is mitigated by Microsoft Security Suite (tm), so the severity of the problem is less than critical so fixing it will be a lesser priority... they've been trying to address security for years now and so far it's been an abject failure - we have no greater confidence in the security of their software now than we did when they started... this could mark the end of their efforts to write more secure code - it could be the sign that they're giving up... writing software to protect people from exploits when you should be fixing the vulnerabilities certainly sounds like a cop-out to me...

so really, there doesn't seem to be any moral highground for microsoft in this venture - either they kill the desktop security software industry by giving their own product away for free (like they did to netscape), or they can charge money for their product and at best admit defeat at writing secure code or at worst be guilty of protection racketeering...

maybe they should just stay out of the security industry entirely... they've tried their hand at it before (msav) and that was an abject failure too...

blogs are dangerous?... wtf?!

well, it looks like some tool over at the bbc thought it would be a good idea to report on how blogs were increasingly being used as a way to get malware onto the computers of people who visit those sites... what this person missed entirely was that blogs are just web pages and the threats they pose are exactly the same as for any other type of website... these are just web threats, web threats of one kind or another have been around for years, there's nothing new here and blogs don't pose any threats that are specific to just blogs...

what really struck me, though was how Viruslist.com picked up on the story and did nothing but parrot the message that blogs pose a threat... they could have set the record straight, they could have explained that these are just the same old threats in the same old medium (the world wide web), but apparently it's more important for them to use this opportunity to urge readers to use anti-virus software (and look at the pretty product placement at the bottom of the page)...

let's be perfectly clear here, web based security threats are not new and packaging them as though they're blog based security threats and are new effectively creates Fear, Uncertainty, and Doubt... the bbc news drone i can forgive for simply being ignorant, but Viruslist.com is part of kaspersky labs so they really should have known better...

scanner decrepitude

a question that just keeps coming back is whether or not it's ok to use an old scanner if you apply the latest signature updates to it... this seems especially popular for NAV, and especially for NAV2002 (symantec take note, you were obviously doing something really well that year, maybe you should go back to that)...

the answer, of course, is no it's not ok... older scanning engines can't make proper, effective use of newer signatures so if you try this you won't be getting the full benefit you could be getting from an anti-virus product...

let's examine why... as new viruses are written, new techniques to confound anti-virus products are employed and so the anti-virus scanning engines need to be updated... it's not enough to just create new signatures, signatures only tell the scanner what to look for not how to look for it...

some people think this is fiction, but some people also believe the earth is flat... it's a demonstrable fact that over time older scanning technologies become obsolete and need to be replaced - the scanning engines in use before polymorphic viruses hit the scene were completely incapable of dealing with polymorphics, so too with macro viruses... those are the extreme examples; there are less critical circumstances where making modifications to the scanning technology is simply more ideal, where the existing technology could have done at least part of the job but to get optimal detection performance a change in the engine is needed...

of course they keep the engine backwards compatible so that it can use all (or at least most) of the old signatures, but there's no such thing as forwards compatibility - older scanning engines can't make proper use of new signatures written to take advantage of the capabilities of newer engines...

as such, you have to keep your scanner engines up to date as well as the signature databases in order to get the full protection the product is supposed to be capable of...

funny business

having one blog is good... having 2 blogs is bad... so says whatever universal process/concept/thing it is that makes me post entries to the wrong blog...

let's be part of the problem

DVForge - Virus Prize 2005
what the hell are these people thinking, offering to pay people to write viruses for the mac and spread them in the wild? like virus writers don't already have enough motivation to write and spread viruses - especially when it comes to being the first one for a new platform or the first one in the wild for a new platform... those sorts of things already make them (in)famous...

these folks have clearly had a break our ethical reality - you do not need a proof of concept virus to prove viruses can spread on the mac - mac OS X is basically a form of unix and the very first viruses that fred cohen wrote when doing his seminal work on viruses back in the '80s worked on unix systems... and they did work, they spread on production systems...

come on, folks - all general pupose computing platforms are susceptible to viruses... all of them... it's been proven - and i don't mean the way you prove things in court with evidence, because there will always be new platforms for which there is no evidence yet... i mean it's been proven on paper with logic - the only facilities a virus needs are those that are already present in the definition of general purpose computer...

these people are not solving any real problem by offering a reward to virus writers for writing yet more viruses (and you know damn well there are going to be a lot more viruses written than rewards handed out)... all they are doing is making virus spreading (because you do need to spread your virus so that it makes it's way onto the target systems naturally in order to get the reward) seem more legitimate by wrapping it up like it's some sort of good deed that puts a set of misconceptions by uninformed people to bed... the fact is that they are soliciting behaviour that is illegal under canadian laws (criminal mischief pertaining to data) as well as laws in a variety of other countries that have unauthorized-access-related legislation...

john mcafee reputedly paid for virus collections and thus became a pariah in the anti-virus industry for supplying virus writers with financial motivation to write viruses... these people here are supplying financial motivation to write & spread viruses and that absolutely contributes to the problem, rather than the solution... these people are not interested in the greater good, they're only interested in making a name for themselves and they don't care how much damage they cause in the process...

update 5:30pm: well, that was quick... seems a lot of people contacted the guy in charge and convinced him to stop the contest... hurray!... now let's move on...

rootkits for windows

this page tries to explain what rootkits are and the emerging threat they pose for the windows platform...

that's all well and good but there's something that just doesn't sit well with me... let's take a closer look:

The term rootkit is very old and is dated back to the days when UNIX ruled the world. Rootkits for the UNIX operating system were typically used to elevate the privileges of a user to the root level (=administrator). This explains the name of this category of tools.

i like this explanation... it's simple, it's consistent, it makes sense.... a rootkit is a tool used to gain root (*nix speak for administrator) privileges...

Rootkits for Windows work in a different way and are typically used to hide malicious software from for example an antivirus scanner. Rootkits are typically not malicious by themselves but are used for malicious purposes by viruses, worms, backdoors and spyware. A virus combined with a rootkit produces what was known as full stealth viruses in the MS-DOS environment.

now this is not so good... apparently rootkits for windows don't really have anything to do with giving a principle administrative privileges... it does a bunch of the other things it's unix counterpart does (i.e. it uses sophisticated techniques to hide) but no elevation of privilege...

does that make sense to you?

if i take the self-replication out of a virus, regardless of the fact that it can still do all the other things it used to be able to do, it is no longer a virus...

why then if i take the root granting functionality out of a rootkit does it remain a rootkit?

it doesn't seem to make a lot of sense, it is not logically consistent... by rights, what they're calling rootkits for windows should be called (in keeping with the spirit of the rootkit name) stealthkits...

now, this was an f-secure description so you may well be thinking that maybe those f-secure folks are a little confused... but no, if that were the case then why does sophos also seem to think that rootkits are more about hiding than they are about privilege elevation (which they don't even mention)... and then there's sysinternal's explanation of rootkits which also focuses on hiding rather than privilege elevation...

this seems like it might actually be industry wide, in which case i can just site here in awe and wonder because the industry appears to be from a completely different planet than you and me...

update from crazyworld

so guess what - Publishing exploit code ruled illegal in France...

guillermito will have to pay 5,000 euros if he publishes security vulnerabilities again... that's right, security research is basically illegal in france now so don't you be making fun of any of those french products that really, really suck...

but wait, there's more (there always is with this case)... if you read this article you'll see that tegam is defending it's actions by saying that guillermito's claims are false and his motives questionable... ooops! if his claims are false then the exploits he supposedly published must not actually exploit weaknesses in the product - in which case he didn't publish exploits, only defamatory material, in which case tegam's current claims against him are baseless... but since a court of law agreed with tegam's claims they must not be baseless, in which case the exploits are real, in which case his claims are true rather than false... you can't have your cake and eat it too, tegam...

i swear this company must be run by untrained monkeys...

legality of virus writing

someone at f-secure is clearly frustrated...

how many times have i seen someone say that virus writing should be illegal? i don't know, i've lost count it's been said so many times... i'm sure it probably seems entirely reasonable too... except wait, oh my goodness, it's not!...

huh? what am i talking about? i'm talking about the fact that enforcing such a law would be an unprecedented contravention of fundamental human rights...

let's face facts - abstracted from all other related activities, simply writing a virus is analogous to writing in a personal journal... it's a matter of freedom of thought and as such one of the most fundamental freedoms there is... it doesn't affect anyone until the writer tries to communicate his/her idea with others... if i write a virus and no one else ever sees it, have i contributed to the virus problem? if i utter a racial slur and no one's around to hear it, have i offended a minority group? no on both counts... what i do in the privacy of my own home or the privacy of my own computer should be of no concern to anyone else...

if you're going to outlaw something, outlaw something that actually causes a problem... outlaw spreading viruses, maybe even outlaw publishing viruses (see here for why full disclosure shouldn't be usable as a valid argument against such free speech limitations), but keep the thought police out of the picture...

that's important so i'll repeat it - outlawing virus writing would be a contravention of a person's freedom of thought, keep the thought police out of the picture...

anti-virus developers, listen up!

take a look here... (Message-ID: wa6dnTcvF_JsK3jcRVn-qA@comcast.com if the link is broken)

this poor user has a virus stuck in his email and he can't figure out which message it is that he needs to delete... folks, do me a favour, when you detect a virus inside what you recognize to be an email envelope could you report not just the virus name and filename but also some kind of identifying information for the email in question (From:, To:, Subject:)?

i mean really - when your product detects a virus in an email database and it can't clean it, without this information you might as well be telling the user "there is a virus somewhere on your computer"... that's just too vague to be useful...

more from crazyworld

f-secure's blog had 2 good links showing both supposed sides of the guillermito vs. tegam issue...

tegam's press release described their displeasure at having their company violently depreciated (violently? ok, maybe thats just a translation thing, but they're obviously trying to appeal to our emotions rather than logic) for years and how a hardheaded search for vulnerabilities (what might otherwise be called persistence) is somehow wrong and unfair and that other companies don't get treated that way (even though they do - one need only look as far as invircible and it's creator zvi netiv for an example of that; martin overton's chekmate didn't escape notice either, and there are plenty more examples)...

guillermito's side seems reasonably well laid out and unmired by marketing double-talk, along with examples (scanned full page advertisements) of tegam claiming he was a terrorist and that the FBI was looking for him...

tegam's press release suggests they're upset at the negative publicity guillermito has caused them, that it's hurt their public image, and yet they are the ones making false terrorist accusations... their legal complaint against guillermito doesn't seem to contest the validity of his claims, it only charges that he reverse engineered their product in a way that was not legal... you'd think if guillermito's claims about their software was false and that it hurt their reputation so much that there would be some sort of charge of defamation or something... i suppose guillermito must have a strong defence against such a defamation charge (like his claims being the truth)...

tegam - stop being such petulant children and take responsibility for your failures...

and in crazyworld, people can go to jail for finding bugs... did i say crazyworld? i meant france...

on fark this would probably get the [Asinine] tag... if you haven't heard about guillermito vs. tegam then count yourself lucky for the bliss that is your ignorance...

long story short: tegam produced a very, very bad anti-virus product, called viguard, and made classic snake-oil claims... guillermito (ok, not his real name but i always go by the first name i know a person by) produces a report that documents how bad the anti-virus is, complete with exploits... tegam sues guillermito for counterfeiting/criminal copyright infringement... guillermito faces 4 months probation in france (kind of a long way to go to see your probation officer when you currently live in the states and are working at harvard - assuming probation works in a similar fashion there) and a hefty fine...

what is the moral of this story? do you think it's that you should keep your mouth shut when companies LIE to the public? do you think it's that france's justice system is borked?

no, the moral of this story is that tegam cannot silence criticism with lawyers - the publicity from this case will point everyone towards the truth - any possibility of them re-establishing secrecy for their product's problems is gone - the only purpose the lawsuit can serve is to punish someone for telling the truth - and on the internet things have a habit of never going away, ever...

the free market works best in the presence of an informed consumer... tegam may win in a court of law, but the court of public opinion is a different beast entirely... vote with your wallet, folks...

viruses and disclosure

let me make this perfectly clear - i do not support the indiscriminate sharing of viral materials...

you should not share viruses, source code, etc. with people you don't know you can trust (both competence and ethics-wise) and you should not ask for such materials from people you have no reason to expect trust from...

the argument for not sharing materials with people you don't know you can trust should be obvious... they might do something bad or stupid with the materials you give them... the argument against asking is that it legitimizes the sharing of materials in situations where it deserves no legitimacy...

there are some misguided notions that the full disclosure policy that works so well for vulnerabilities would be equally well applied to viruses... lets examine that more closely...

a vulnerability, ultimately, is a mistake... whether it's a mistake in the design or in the implementation doesn't matter, it's a mistake that in an ideal world could have been avoided and in the real world can (hopefully) be fixed... full disclosure of vulnerabilities benefits us in a variety of ways...

1. first and foremost it places pressure on the people/organization responsible to fix the problem in a more timely manner than they may have otherwise been inclined to do.
2. it helps us learn more about the mistake so that in the future we might better avoid it or similar mistakes.
3. it helps us identify when a program or system no longer meets our expectations of trustworthiness if/when an unacceptable number of vulnerabilities are uncovered or not enough is done to rectify them.

viruses, on the other hand, are not mistakes nor do they depend on mistakes (though some particular viruses may depend on particular vulnerabilities)... the ability to support viral infection is inherent to ALL general purpose computing platforms... it cannot be fixed or avoided - and since it cannot be fixed or avoided, it cannot be used as a discriminating factor when judging the quality of the platform or organization (the fact that windows has more viruses than linux has more to do with the number of windows users there are and the nature of those users than with the fact that windows is garbage)... none of the benefits we receive from full disclosure of vulnerabilities are achievable in the virus realm... what is achievable is

1. a state where it is easier for people learning to write and spread viruses to get their hands on examples.
2. a state where it is easier for people who wish to use existing viruses as weapons of vengeance to get their hands on viruses.
3. a state where it is easier for novices to get their hands on samples even though they don't have sufficient competence with viruses to deal with them safely.

as such, sharing viruses with people you don't know you can trust cannot be considered to be responsible handling of viral materials and is to be discouraged... instead, one should only share such materials with people one knows one can trust (who in turn do the same - leading to a 'web of trust') and only request such materials from those who you can reasonably expect will trust you...

vx'er crackdown

Police raided another virus writer
Benny, Ratter questioned

looks like law enforcement is starting to get more serious (and capable) about getting their hands on virus writers... i said this kind of thing was coming, years ago, but do the vx'ers listen to me? no...

well ok, maybe some of them did... but obviously not enough...

there should be billboards with pictures of stern looking cops and captions that read "write viruses? that's fine. let 'em out and you're mine."...

and i'm not even suggesting that the vx'ers referenced in those articles actually let anything out - but obviously someone has been doing so, and that endangers the whole 'scene'...