AV complicity explained

earlier this week i wrote a post about the idea of the AV industry being somehow complicit in the government spying that has been all over the news for months. some people seemed to really 'get it' while others, for various reasons, did not; so i thought i'd try to be a little more clear about my thoughts on the subject.

the question that the EFF et al have put towards the AV industry (besides having already been asked and answered some years ago) is a little banal, a little pedestrian, a little sterile. real life is messy and complicated and things don't always fit into neat little boxes. i wanted to try to get people to think outside the box with respect to complicity, what it means, what it would look like, etc. but i think some people have a hard time letting go of the straightforward question of complicity that has been put forward so let's start by talking about that.

has the NSA (or other organization) asked members of the AV industry to look the other way and has the AV industry (or parts thereof) agreed to that request? almost certainly the NSA has not made such a request, for at least a couple of reasons:

1. telling people about your super-secret malware is just plain bad OpSec. if you want to keep something secret, the last thing you want to do is tell dozens of armies of reverse engineers to look the other way.
2. too many of the companies that make up the AV industry are based out of foreign countries and so are in no way answerable to the NSA or any other single intelligence organization.
3. there's quite literally no need. there are already well established techniques for making malware that AV software doesn't currently detect. commercial malware writers have been honing this craft for years and it seems ridiculous to suggest that a well-funded intelligence agency would be any less capable.

now while it seems comical that such a request would be made, to suggest that the AV industry would agree to such a request would probably best be described as insulting. whatever you might think of the AV industry, there are quite a few highly principled individuals working in that would flat out refuse, in all likelihood regardless of what their employer decided (in the hypothetical case that the pointy-haired bosses in AV aren't quite as principled).

now please feel free to enjoy a sigh of relief over the fact that i don't think the AV industry has secretly agreed to get into bed with the NSA and help them spy on people.

done? good, because now we're going to take a deeper look at the nature of complicity and the rest of this post is probably not going to be nearly as pleasant.

here's one of the very first things wikipedia has to say about complicity:

An individual is complicit in a crime if he/she is aware of its occurrence and has the ability to report the crime, but fails to do so. As such, the individual effectively allows criminals to carry out a crime despite possibly being able to stop them, either directly or by contacting the authorities, thus making the individual a de facto accessory to the crime rather than an innocent bystander.

in the case of government spying we may or may not be talking about a crime. the government says they broke no law and observers speculate that that may be because they've subverted the law (much like they subverted encryption algorithms). so let's consider a version of this that relates to ethical and/or moral wrong-doing instead of legal wrong-doing:

an individual is complicit in wrong-doing if he/she is aware of it's occurrence and has the ability to alert relevant parties but fails to do so. as such, the individual effectively allows immoral or unethical people to carry out their wrong-doing despite possibly being able to stop them either directly or by alerting others who can, thus making the individual a de facto accessory to the wrong-doing rather than an innocent bystander.

in this context, could the AV industry be complicit with government spying? perhaps not directly, not in the sense that they saw what the government was doing and failed to alert people to that wrong-doing. however, what about a different wrong-doing by a different entity but still related to the government spying?

hbgary wrote spyware for the government. this became public knowledge in the beginning of 2011. by providing the government with tools to perpetrate spying they become accessories to that spying.

hbgary was and is a partner of mcafee. now what is the nature of this partnership? hbgary is an integration partner. they make technology that integrates into mcafee's endpoint security product to extend it's functionality. mcafee does marketing/advertising for this technology and by extension for hbgary, giving them exposure, lending them credibility, and generally helping them make money. that money is almost certainly re-invested into research and development of hbgary's products, which includes governmental malware that's used for spying on people/organizations. there are mcafee customers out there right now whose security suite includes components that were written by known malware writers and endorsed by mcafee (although they make sure to weasel out of responsibility for anything going wrong with those components with some fine print). mcafee didn't break off the partnership when hbgary's status as an accessory to government spying became known, and since they didn't break off the partnership you can probably make a safe bet that they didn't warn those customers that part of their security suite was made by people aiding the government in spying either. even if we ignore the fact that mcafee aids a business that writes malware for the government, mcafee's failure to raise the alarm about the possible compromising nature of any content provided by hbgary makes them accessories to hbgary's wrong-doing. by breaking ties with hbgary and warning the public about what hbgary was up to they could have had a serious impact on hbgary's cash flow and hurt their ability to win contracts and/or execute on their more offensive espionage-assisting projects. they didn't do any of that and that makes them complicit in the sense discussed a few paragraphs earlier.

the rest of the AV industry may not be directly aiding hbgary's business but, like mcafee, they have failed to raise any alarm about hbgary. they could have done much the same as mcafee by warning the public, with the added bonus that they would have hurt one of the biggest competitors in their own industry while they were at it and that would have benefited all of them (except mcafee, of course). again, failing to act to help prevent wrong-doing makes them a de facto accessory to that wrong-doing. the AV industry as a whole is complicit in the sense discussed earlier.

of course, the AV industry isn't alone in being accessories to an accessory to government spying, and that brings up a consideration that should not be overlooked because there is a larger context here. historically, the culture of the AV industry has been one that values being very selective in things like who to trust, who to accept into certain groups, etc. add to that a very narrowly defined mission statement (to fight viruses and other malware) and it's little wonder that the ethical boundaries that developed in the early days were so dead-set against hiring, paying, or doing anything else that might assist malware writers or possibly promote malware writing. heck, i knew one member who wouldn't even engage viruses writers in conversation, and another who said he was wary of hiring anyone who already knew about viruses just in case they came by that knowledge through unsavoury means. aiding malware writers, turning a blind eye to their activities, etc. are things that normally would have violated AV's early ethical boundaries.

by contrast, the broader security industry is highly inclusive and has long viewed the AV industry's selectivity as unfair elitism. that inclusivity means that the security industry isn't actually just one homogeneous group. there are many groups, from cryptographers to security operations personnel to vulnerability researchers to penetration testers, etc. each one has it's own distinct mission statement and it's own code of ethics. what do you think you get from a highly inclusive melting pot of security disciplines? well, in order for them to tolerate each other, one necessary outcome is a very relaxed ethical 'soup'. many quarters openly embrace the more offensive security-related disciplines such as malware creation. in order for AV to integrate into this broader security community (and they have been, gradually, over time), AV has to loosen it's own ethical restrictions and be more accepting.

so while the AV industry failed to raise the alarm about hbgary, the broader security industry failed as well. the difference is that ethics in the security industry don't necessarily require raising an alarm over what was going on. hbgary is a respected company in security industry circles and it's founder greg hoglund is a respected researcher whose proclivity for creating malware has been known for a long, long time. as far as the security industry is concerned, hbgary's activities don't necessary qualify as ethical wrong-doing. there will probably be those who think it does, but in general the ethical soup will be permissive enough to allow it, and without being able to call something "wrong-doing" there can be no complicity. this is where AV is going as it continues to integrate into the broader security community. in fact it may be there already. maybe that's the reason they didn't raise the alarm - because they've become ethically compromised, not as a result of a request from some intelligence organization, but as a result of trying to fit in and be something other than what they used to be.

in the final analysis, if you were hoping for a yes or no answer to the question of whether AV is in any way complicit in the spying that the government has been doing (specifically, the spying done using malware), i'm afraid you're going to be disappointed. it depends. based on AV's earlier ethics the answer would probably be yes. based on the security community's ethics the answer may well be no. where is the AV industry now? somewhere between what they were and what the broader security community is. ethical relativity is unfortunately a significant complicating factor. then again, i'm an uncompromising bastard, so i say "yes" (after all, i did grow up with those old-school ethics).

ethical conflict in the anti-malware domain

forgive my silence over the last little while. motivation to blog sometimes isn't easy to find. as time wears on, fewer and fewer things get under my skin enough to drive me to rant (is that what it means to mellow with age?). but since you're reading this i think you can guess what this post infers.

five years ago i wrote a post about what i perceived as an ethical conflict in the anti-'rootkit' domain. it detailed the actions of two of the most notorious names in stealthkit research, jamie butler and greg hoglund, and how they were profiting from making a particular niche of the malware problem more popular (and thus, inevitably a bigger problem).

one of the things i pointed out was that symantec was working with a start-up company (komoku) that had jamie butler (author of what was at one time one of the most widely deployed stealthkits around) as it's chief technology officer. i thought the fact that an anti-malware company was in bed with a company that hired such a high profile malware writer deserved at least a moment of reflection, considering the hard-line stance anti-malware companies take on hiring malware writers themselves. at the end of the day, mind you, that start-up was focused on prevention so maybe the argument could be made that mr. butler had or was trying to reform in some way. (mr. butler has since moved on to mandiant, along with his disciple {the FU2 to butler's FU} peter silberman)

when i read earlier this past week that another anti-malware company (mcafee) had been working with greg hoglund's company (hbgary) i thought it an interesting historical footnote but paid little attention to it beyond that (though, if i had remembered that mcafee had once been pointing fingers at rootkitDOTcom, maybe the hypocrisy would have stood out more). after all, little attention seemed to be paid to such connections five years ago so why should this time be any different? well, that was before i knew what hbgary was in to.

apparently, on top of the legitimate work that one can find out about by visiting the hbgary website (which of course i won't link to), it appears that hbgary also writes and sells malware for fairly large sums of money. the customers for their malware include the government/military but might not stop there. even if that set of customers does stop there, hbgary appears to be in the high-end commercial malware business.

so where does that leave mcafee? it leaves them in bed with commercial malware writers. while AV companies have been proclaiming for decades that they don't and won't hire malware writers, apparently they don't have to. they can simply partner with the boutique security shops that do. clearly they are not picking their business associates as carefully as they are their actual employees.

and then there's the claim that surfaces from time to time that AV companies won't make special provisions to keep malware deployed by the authorities from getting detected. what's the point of making such a claim if you're just going to turn around and do business with the company that may very well be making said malware?

how many other AV companies, besides mcafee, were or are in bed with hbgary? how many are in bed with companies LIKE hbgary? where's their ethical high horse when it comes to partnerships? why wasn't the "malware writers need not apply" policy updated when commercial malware became the norm and presented the loophole we see before us today?

some AV companies are rewarding malware writers financially. it may not be in the ways we traditionally thought of, but with the #2 company in the industry involved in this practice (and arguably the #1 company as well, depending on where you want to draw the line), the end result is AV companies contributing to the commercial success of malware writers, and that is not ok at all.

greg hoglund thinks rootkits AREN'T malware

that was just about the funniest thing i've read all day... greg hoglund, of rootkitDOTcom fame, has written a little piece about the threat posed by the fact that the malware term (rootkit) he and his 'rootkit' community hijacked so many years ago is getting associated with malware... well duh!

he starts out with a straight-forward statement:

Rootkits are under attack in the press and it’s very important for the rootkit community to stand up for their technology.

and that statement happens to be correct, the media are vilifying stealthkits (what passes for a rootkit now-a-days)... they've got a good reason, though - stealth is being used almost exclusively for bad deeds, be it in spyware or botnets or DRM...

he goes on to say:

Rootkits are about hiding data. There are legitimate reasons to hide data both personally and in the enterprise.

which i agree with to a point, there are circumstances where you want to prevent idle tampering by some users in order to keep them from damaging the system, but the stealth technology he's talking about goes far beyond that - it hides things even from the administrator and there's no justification for that...

some of the things he's written are just wacky, like:

Many people are implying that rootkits are inherently deceptive. Deceptive is a strong word, too strong. Deception is an intent, not a technology.

the technology manipulates part of the system in order to make it lie to other parts of the system and/or the user about what is really there... i can't see how one would not interpret lying and manipulation as deception...

another off the wall statement is the following:

Rootkits would be unnecessary if the operating system already had reliable data hiding features. Current operating system security controls, such as the “hidden” property on a file, are easily defeated. Overall, the operating system does not supply the required architecture enabling us to hide data.

apparently hoglund has never heard of file system permissions, a feature available on NTFS as well as most *nix-related file systems... sure the administrator can bypass those - because s/he's the administrator... the administrator of a machine has legitimate authority to control what goes on on that machine - i don't care what you think your stealth technology may be protecting, your right to protect it does not supersede the rights of the system administrator to control that machine (a variation on the "your right to swing your fists ends at my nose")... of course file system permissions are not totally secure - but then again, nothing is... barring exploits or configuration errors, a more limited user should not be able to bypass the restrictions enabled through file system permissions and that should be as reliable as any stealthkit...

hiding things is an ethical issue, and he recognizes that when he writes:

The ethical question tends to orbit the idea of “user control”. Some people argue that because rootkits thwart user control, they are unethical. But there is a very simple answer to this: if a rootkit can be removed from a system (by authorized personell) with no long lasting repercussion upon the system then user-control is maintained. Of course, the employee might not agree, but they are not the user in this case. The administrators of the network are the legitimate users and they never lose control.

but what he doesn't seem to realize is that when the stealthkit hides things from even the administrator, regardless of whether or not the administrator can remove it, the administrator has lost control... removing the malware is just an attempt at regaining control, not an indication that control was never lost... while it was hiding things (from even the administrator) there are all kinds of things it could have done that could go undetected and remain that way once removed like leaking sensitive information, giving remote access to a 3rd party, or carrying out various types of network attacks... none of those things would have long lasting repercussions that could be directly linked with the stealth technology with any degree of certainty...

he ends off with:

The rootkit community contributes a wealth of information and capabilities for those of us who protect networks and data. Rootkits are as good as you want them to be.

but when he also says things like:

Rootkits are largely security through obscurity.

and:

As usual, we have to take measures of control based on security through obscurity (which, debatedly, is the most effective kind of security - supposedly secure non-obscure systems have been exploited ad nauseum).

you better believe we don't want that kind of protection for our data and networks... i mean come on, security through obscurity? is someone unfamiliar with shannon's maxim? stealth security absolutely is an obscurity-based attempt at security, he's right about that, but thinking that we'd want that (or worse that it's actually effective?) is absurd...

ethical conflict in the anti-'rootkit' domain

not long ago i blogged about how anti-virus companies don't hire virus writers... now of course there was a somewhat high profile exception involving low profile company (ie. small start-up so far removed from the av industry they didn't know how badly they'd be shooting themselves in the foot) but this example is the exception that proves the rule...

but now i'd like to shed some light on a similar example in the so-called 'rootkit' domain... in a securityfocus.com article from last year we have the following:

Jamie Butler: I am a kernel developer and contributor at rootkit.com, where I go by the name Fuzen. I really enjoyed working with Greg on the book Rootkits: Subverting the Windows Kernel. Most of my time is spent at the bit and byte level.

and

Jamie Butler: I am not sure of the exact time frame that I learned about rootkits. I guess I knew of their existence since the early UNIX Trojan system file replacements. However, I did not become active in the research until 2001 when I was working on my Master's degree. At that time, I was looking for modifications to the operating system in memory used to hide things. After that research, I realized that you could alter data structures directly in kernel memory to hide without modifying any operating system code. That is what the FU rootkit, which I wrote, is intended to demonstrate. It is not malicious but more proof of a premise.

and finally

Greg Hoglund: Not really - I don't spend much time trying to detect rootkits. But, I do know that FU is one of the most widely deployed rootkits in the world. [It] seems to be the rootkit of choice for spyware and bot networks right now, and I've heard that they don't even bother recompiling the source - that the DLL's found in spyware match the checksum of the precompiled stuff available for download from rootkit.com. I think that is kinda lame, these spyware guys don't even bother to use the source.

did you catch that? jamie butler (aka fuzen) created what became one of the most widely deployed 'rootkits' in the world (not the only 'rootkit' he's authored, by the way)... and then he co-authored what some have described as the only book on 'rootkits'...

so? how does that relate to av companies who hire or don't hire virus writers? well, how about this - the same jamie butler is the CTO of komoku, a company that has received $2.4 million from various branches of the US government to develop a solution to the 'rootkit' problem in the form of CoPilot and Gamma... Gamma, being a software product, is intended to be priced similarly to anti-virus products but won't be as successful against 'rootkits' because it's software only... CoPilot, on the other hand, is a hardware product that will probably be going for about $1000 a pop so they'll be pulling down some major cash when they finally get to market... oh, and did i mention they've partnered with symantec?

but wait, there's more - while working for hoglund's security company (hbgary) butler developed a 'rootkit detection technology called VICE and now he and peter silberman (who has also worked at hbgary and authored the FUTo 'rootkit' which is also freely available on hoglund's site) have developed yet another 'rootkit' detection technology called RAIDE - it's still too new for a business to be made out of it yet, we'll have to wait and see...

let me boil that down for you - jamie butler created the FU 'rootkit'... jamie butler and greg hoglund made FU available for free download on greg hoglund's 'rootkit' site... jamie butler and greg hoglund wrote the only book on this new threat, marking them both as experts in the field... FU, a 'rootkit' written by one of the foremost experts in the 'rootkit' field became one of the most popular 'rootkits' amongst those who deploy them, in fact the exact binaries that jamie butler and greg hoglund make available are the same ones getting deployed and greg hoglund admits it... jamie butler and greg hoglund get money for a book about a problem they actively contribute to... jamie butler, while working for greg hoglund, develops anti-'rootkit' technolog - free to use but still it draws people to hoglund's other products and so they both get money as a result of technology meant to thwart a problem they actively contribute to... jamie butler, being an expert in the field, is hired and made CTO by an anti-'rootkit' company called komoku which in turn gets millions from the government and so jamie butler gets still more money for working on technology meant to thwart a problem he actively contributes to... symantec, who correctly refuses to hire virus writers, partners with a company that has a 'rootkit' writer and distributor as their CTO... jamie butler and peter silberman, both 'rootkit' authors whose works are freely downloadable from hoglund's site, develop yet another technology meant to thwart a problem they both actively contribute to ....

so there you have it - people creating, distributing, advertizing, and evangelizing 'rootkits' - basically contributing to the problem by creating the tools, popularizing the threat, and arming the bad guys... and then some write a book about the problem or actually create products to solve the problem and in so doing rake in lots of dough... if this were going on in the anti-virus industry people would be raising a big stink, and it's not like anyone would trust an anti-spam company that hired spammers, so what the heck is going on here? how are these people getting away with this?

VICE? RAIDE? CoPilot or Gamma? i certainly won't be touching any of those with a 10' barge pole - give me sysinternals rootkit revealer or f-secure's blacklight, thanks... i'd rather not support people who are actively part of the problem... it's a shame the US government doesn't feel the same way... also a shame symantec doesn't feel that way - not sure why they seem to have less problems with 'rootkit' creators than with virus writers...

mcafee's rootkit report: an alternative interpretation

the internet has been relatively a-buzz this week over a report (well, part of a report, actually - don't ask me why they couldn't release the whole thing) out of mcafee on the growth of the 'rootkit' threat... a lot of attention has been paid to mcafee's rather poor choice of words when the key findings blamed the "open source environment" for the increased proliferation and complexity of rootkits...

first, yes it really has nothing to do with "open source"... the concept that the author was probably struggling for when he settled on "open source" was public or full disclosure... a software licensing paradigm has nothing to do with 'rootkits' getting more complex or being deployed more frequently, but public disclosure is an enabling practice... coming out against full disclosure or anything like it isn't a popular thing to do in security circles these days, though, which may be why the author tried to find some other term...

also, mcafee named and shamed rootkitDOTcom as a possible leading cause of the worsening 'rootkit' problem... a lot of people took issue with this, mostly they're the folks who feel rootkitDOTcom is doing nothing more than practicing full disclosure and that full disclosure can do no wrong... some even try to quote bruce schneier with the old "security by obscurity is no security at all" line and to those people i'll direct you to what bruce schneier has actually written about full disclosure, particularly about irresponsible (and perhaps even criminal) disclosure...

now mcafee has it partially right, the public disclosure taking place on rootkitDOTcom and various collaboration sites and blogs IS at least partially responsible for the increase in complexity of 'rootkits'... by sharing malware source code and even compiled binaries with literally everyone (as rootkitDOTcom does) the supposed good guys are adding their voices, their knowledge, and their skills to the collaborative efforts of the bad guys...

that said, mcafee's figures show something in the growth patterns that availability of information cannot explain... collaboration sites in general and rootkitDOTcom in particular have been around for years so why then does the growth rate change so dramatically when it gets to 2005? availability of source and binaries are enabling factors, not causative ones - they don't drive the innovation or deployment of this type of malware...

something changed, something happened in 2005 that made 'rootkits' a whole lot more popular - i'll give you 3 guesses as to what that was and the first 2 don't count... that's right, sony bmg / first4internet / xcp... the media circus surrounding that debacle kept 'rootkits' in the public eye for a long time... it made them mainstream, not only in the eyes of the general internet public but in the malware creators' eyes as well... the attackers interest was piqued, their imagination was sparked, the tools they needed were easy to find and so now we are witnessing something not that unlike the slashdot effect except in malware development... throngs of people who weren't making 'rootkits' before, who probably weren't even aware of the kind of stealth technology that was available or how it could be used to their advantage, now are and that's what mcafee's numbers represent...

does that mean the media is to blame for building all this interest in 'rootkits'? maybe - i'd certainly like to blame some of the ills of the world on their sensationalism... the bad guys are still the ones responsible for doing bad things, but the media pointed a whole bunch of them in a new direction... that doesn't mean that greg hoglund and co. of rootkitDOTcom are off the hook, though... for all protestations of helping people learn about threats, learning for the sake of learning doesn't improve security - they aren't helping to close the window of exposure for this class of threat but they are helping to arm the bad guys... that's called being part of the problem rather than part of the solution...

why virtual machine based 'rootkits' won't be the next big problem

ok, ignoring the issue of what rootkits really are for the moment, let's examine this idea of rootkits that are so low level they're even below the OS...

first, as greg hoglund points out you're pretty much guaranteed to notice the performance hit when your entire OS gets dropped into a virtual machine...

second, as pointed out on the f-secure blog it's actually been done before over a decade ago, back when stealth was still called stealth...

but really, i think i'm going to go them both one better (at least) and say that we solved the full stealth problem over a decade ago... that solution was called booting from a known clean bootable floppy disk and scanning with a known virus scanner...

"but kurt, how are we supposed to use our generic rootkit detection technology if the rootkit isn't active?" - simple, you aren't... those sorts of generics require the malware to be active, which gives it a tactical advantage (it's able to actively defend itself then)... it also allows the malware to know more about the security application than the security application knows about the malware, which is another tactical advantage for the malware... if you're unfamiliar with what sun tsu had to say about engaging the enemy when you're at a disadvantage then i suggest you go do your homework right now... you can't rely solely on generics that way - known-malware techniques (know your enemy) must be employed in an environment and under conditions of your choosing in order to maximize your tactical advantage, and the generics are then used in a supporting role to partially cover what that strategy can't...

now, those of you who've been following things for a few years now you probably know that microsoft screwed that option up with the advent of NTFS... no version of MSDOS is capable of parsing an NTFS partition natively and microsoft seems unwilling to do much about that - probably because so far there really hasn't been that great a need these days... however, should the need arise a fair amount of effort has gone into correcting microsoft's oversight... things like bart's pe disk, NTFS4DOS, or any one of the many recovery oriented live-cd linux distributions can give you access to an NTFS partition after booting from a known clean bootable medium...

all in all, the majority of what's being said out there about microsoft's subvirt and the technology it represents is just hype... in the very unlikely event that anyone ever actually bothers trying to deploy it in the wild, it's an old problem that we've had a solution for for some time now...

[obligatory terminology rant]
of course all of this is one of the consequences of the rootkit redefinition... it clouds the issues in both the rootkit problem-space and the stealth problem-space... we wouldn't be forgetting this history if stealth was still called stealth, and then maybe the brain-trust at microsoft wouldn't have to spend untold millions reinventing the wheel that we already know how to deal with...
[/obligatory terminology rant]

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