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.

learning from the past

saw this post on the agnitum blog about how an older version of their technology was being detected as a stealthkit... basically they were keeping integrity information about files that had been previously scanned to optimize future scanning (no need to scan a file that hasn't changed) and hiding that integrity information using all too familiar means...

it reminded me of two things - first is yisreal radai's nearly 15 year old paper on integrity checking (due to his conclusion that to truly protect integrity information from attack it must be stored offline) and the second is the witch hunt that resulted from the misguided redefinition of rootkit to be anything that hides things (which has already dinged other security vendors - especially kaspersky for remarkably similar reasons)...

as the saying goes - those who cannot remember the past are condemned to repeat it...

eEye and malware creation ethics

wow, i just got done throwing out a mention to the new MBR stealthkit and now i find out it's pedigree...

folks, it's time you go over your malware researchers with a fine-tooth comb because i don't think anybody in the industry really wants to be responsible for another proof of concept getting into the wild...

that is, unless you're eEye digital security, apparently... not only was it their researchers derek soeder and ryan permeh that created bootroot and presented it at blackhat in 2005, but even as i type eEye is hosting that malware on their website right now...

this is absolutely NOT responsible behaviour and the people who were and are responsible for both the stealthkit and the company should be ashamed of themselves for being part of the problem instead of part of the solution... anti-malware researchers and companies should not be creating and distributing malware - this is so fundamentally wrong i'm actually tongue-tied trying to describe how wrong it is... needless to say i won't be touching anything of theirs with a 10 foot barge pole and others might want to consider the same...

*update* - tyler reguly caught or otherwise helped me see a factual error i made... the stealthkit in the wild is not the exact one developed and distributed by eEye but rather is a modified version of it... that doesn't really change much, however, because they still armed the bad guys...

ethical conflict in the anti-'rootkit' domain - part 2.1

sometimes microsoft hires really good people like jimmy kuo and sometimes they really screw up and hire folks you maybe wouldn't want to meet in a dark alley... that seems to have happened with their acquisition of ep_xoff et all behind rootkit unhooker... you may recall i posted about this individual once before in relation to an apparent ethical conflict (ep_xoff wrote and released a stealthkit, or 'rootkit' for those drinking the rootkitDOTcom koolaid, capable of bypassing all stealthkit detectors save possibly microsoft's own strider winpe ghostbuster technology)...

what i didn't post about before were his reactions to the concerns expressed by myself and cd-man (here)... while his criticisms of me were little more than childish, according to dmitry sokolov, ep_xoff veered more into the realm of criminal behaviour by attempting to incite a DDoS against or defacement of cd-man's blog...

normally i would say that hiring such a goon would reflect poorly on a company, but since microsoft's moral compass isn't really known for pointing to true north, i suppose i shouldn't have expected better from them...

ethical conflict in the anti-'rootkit' domain - part 2

while jamie butler, the creator/distributor of one of the most widely deployed stealthkits in the world (as i pointed out previously), is no longer the CTO of the government/military funded anti-stealthkit startup komoku (oh, to have been a fly on that wall), there's a new conflict to grab the spotlight...

found on the anti-rootkit blog a couple days ago, apparently the creator of a program called rootkit unhooker have created a stealthkit called unreal that no one (not even his own product) can detect and he's planning to release it...

tell me something - what kind of a world do we live in where people who are supposed to be anti-X go around making X's? if anti-virus vendors created and released viruses all hell would break loose... could you imagine buying anti-spam technology that you read about in a spam email? would you use an anti-spyware app created by people who make spyware?

so this person, known as EP_XOFF (wow, that instills confidence), expects people to trust his stealthkit detector after he's built and released a stealthkit that not even his own product detects? aside from the fact that he's just demonstrated that neither his nor any other detector is able to protect you (so far only outside-the-box cross-view analysis is going to pick it up and none of the mainstream stealthkit detectors use that technique), you now have to wonder if his detector actually comes with a similarly undetectable stealthkit that you don't know about... how could you know one way or another? and why would you trust someone whose making the technology to bypass all stealthkit detectors available for people to download and modify for their own ends?

i mean, i understand trying to find ways to break the security of something, but when it's the security in applications like the one you yourself make shouldn't you first come up with ways to prevent that break before giving the attack information to the public? who is he serving by releasing the info before even his own product is able to deal with it because it sure doesn't seem like he's serving the end user? though he may not be earning money off of making the problem worse as others have, there are still plenty of personal rewards he will almost certainly reap such as notoriety, influence, and social standing in the stealthkit research community...

what this all boils down to is this: EP_XOFF is gaining rewards at everyone else's expense... this is not the way you want your security software provider to behave...

where do stealthkit detectors belong

mike rothman brought up an interesting point today in a section of his daily incite - where does stealthkit (rootkit to those of you drinking the revisionist rootkit koolaid) belong? inside a larger security application suite (or perhaps a larger security application period) or on it's own as a separate tool? although they're often separate right now, mike thinks they probably shouldn't be...

but given how they operate and how best the fundamental technique they employ can be used, is merging them into larger products really reasonable?

most stealthkit detectors employ a generic detection technique known as a cross-view diff or cross-view analysis where essentially you look at some area of the computer in 2 or more different ways and see if there are any discrepancies between them... although most stealthkit detectors are trying to cut this particular corner, outside-the-box analysis is ultimately necessary to truly see through persistent stealthed malware... the av industry knew this back in the 90's (it was called clean booting back then, though microsoft has since recycled that term) but got microsoft's boot up their ass when NTFS became mainstream without any robust method to perform outside-the-box analysis on that type of file system so they've been squeaking by with safe-mode ever since... anti-spyware and other anti-malware apps that grew up in the interim have never even dealt with this methodology because active stealth went out of fashion for a number of years but for an anti-malware that deals specifically with stealth in a generic sort of way at least part of it's operation really should be done outside-the-box and that is going to set it apart from other anti-malware functionality...

as yet the only detector i know of that does an outside-the-box cross-view diff is the WinPE implementation of microsoft's strider ghostbuster rootkit detection technology but that's still just a research project... no one else does it because as yet microsoft have not made WinPE easily available to the public (though i've heard rumors this may change with vista) and the alternative, BartPE, must be generated by the user (due to copyright and licensing restrictions from microsoft) rather than distributed with the stealthkit detector, which is a not-so-simple task from the perspective of average-joe computer users...

but if the anti-stealthkit folks were to do things right, how well would the resulting product (that runs off a bootable cd) fit in with existing security apps? not very well would be my guess... it would be nice if anti-virus and other anti-malware apps could operate in a similar outside-the-box environment since stealth is just a means to hide what eventually becomes known-malware, but that defies centralized management consoles and scheduled scans and a variety of other convenience features (bloat) that they've accumulated over the years... outside-the-box is fundamentally at odds with convenience but it's necessary for reliable generic detection of stealthed objects so how can you reconcile stealth malware detection with the increasingly convenient unified anti-malware product?

blue pill 2.0

have you heard the news about a new version of the blue pill?

there have been a number of nails in the coffin of the blue pill that i never bothered commenting on, mostly because i felt i'd already said enough... the final nail in the coffin, i think, should be the fact that joanna rutkowska herself is now working on the next version which is supposed to be even stealthier (stealthier than 100% undetectable?)... clearly then, the blue pill was not 100% undetectable and all those people who said so were proven right...

but this is not an i told you so...

see, version 2.0 is supposed to be truely 100% undetectable (at least that's the goal)... 1.0 fell victim to certain technical issues that joanna hopes to address in the next version...

what she won't be addressing (because it can't be addressed) are the theoretical issues that make 100% undetectable malware impossible... stealth is a protective measure and 100% effective stealth implies that perfect protection is possible when in fact we know this is axiomatically false... blue pill 2.0 won't meet the 100% undetectable snake oil goal joanna has set for it anymore than v1.0 did, nor will version 3 or 4 or 65...

see, this isn't an i told you so, it's an i'm telling you so again because somebody wasn't listening the first time...

the blue pill is NOT 100% undetectable

that's right, the blue pill is not 100% undetectable...

i was amazed at the number of writers swallowing the "100% undetectable" bit hook, line, and sinker... clearly people aren't really thinking things through...

and i'm not even referring to my previous post on the blue pill, that was really just conjecture... i don't know it will work, nobody knows what will work against the blue pill because nobody's seen the blue pill yet except the researchers involved... i suspect that a pre-emptive tactical move to secure privileged virtualization resources can be used to foil next-gen vm-based stealth but it's all just guesses right now...

no, now i'm going to go back to first principles... let's start with some background - there is no perfect protection... this is a truism, an axiom, and something that the bad guys will tell you ad nauseam* in trying to show you that your security mechanisms, no matter how good, are flawed... and you know what they're absolutely right, there is no perfect protection - but watch out if you try to turn that attitude around on them 'cause you will get flamed... you see there are true believers out there, pro-malware zealots who in one breath will gleefully expound on how your security efforts are vulnerable to this or that in an attempt to feel superior for being on the supposed winning side in the malware/anti-malware battle and then in the next breath go ballistic when you suggest that the same principle applies to the tricks and techniques that malware writers use to protect their malware from security apps...

yes, that's right, stealth is nothing more than a protection mechanism (one of many as a matter of fact) that facilitate malware persistence and if there can be no perfect protection then there can be no perfect stealth, no 100% undetectability... nada, zilch... if the blue pill were to turn out to be the exception then we would study it and learn from it and build more perfect protection techniques - the same fundamental principles that apply to good software must apply to bad software too and vice versa, it's all just software after all...

what's more, i can't believe nobody is catching the scent of snake oil... i mean come on, 100% undetectable should sound as impossible as 100% detection...

no, the blue pill is not 100% undetectable, it cannot be, it would violate one of the most fundamental principles in security... it may very well be undetectable by current products but that's just not the same thing... by that logic new viruses are 100% undetectable --- until they're not...

[edit * thanks for the spelling correction, edgewalker]

the blue pill is hard to swallow

i've blogged before about virtual machine based stealthkits and i was pretty dismissive of the idea so you might think there was nothing more for me to say about the subject now that another one has been proposed (except maybe to say "not another one!")...

well here's my mea culpa... while the method of booting clean to get a baseline snapshot of the system to compare to when trying to generically detect the presence of active stealth techniques (outside-the-box cross-view difference detection) is still quite effective against conventional stealth malware, joanna rutkowska presents an idea for stealth where that just won't work... in memory only malware won't be found on the disk after a clean boot so the outside-the-box method won't work... also, stealth born out of moving the entire operating system into a virtualization layer (vm-based stealth) has the potential to make the malware invisible in memory - so it would seem like it's the perfect stealth...

and indeed it's getting called completely undetectable, but for me that's a little hard to swallow so i got to thinking - how would you attack something like this?.. the best way to attack malware is to find some scenario where it's not in control... clean booting doesn't get us there in this case because the malware will be entirely gone so there won't be anything to find... in-situ cross-view analysis won't work either because everything's within the malware's virtualization layer...

but what if something wasn't inside the malware's virtualization layer? in fact, what if the malware itself got executed inside of a virtualized system? a sandbox using virualization technology as advanced as that which the malware uses, designed not to do bad things but rather to look for the tell-tale signs of active stealth (especially vm-based stealth)...

if undetectable virtualization technology can be used to hide the presence of malware, then equally undetectable virtualization technology pre-emptively deployed on the system should be able to detect the undetectable vm-based stealth malware if/when it is encountered...

mcafee on the possibility of cell phone stealthkits

the mcafee avert blog has a post on it expressing concerns that the recent release of symbian ROM images and research may lead to the development of stealthkits (what mcafee and most of the rest of the industry are currently referring to as rootkits) for cell phones...

after their stealthkit report of a couple of months ago it would be easy to interpret their newly expressed concern as meaning they feel that the ROMs and research should not have been released...

i don't know if that was actually the intention of the mcafee blogger in question, but just in case: you cannot use the threat that security research could be used for nefarious purposes as a means to justify stifling the public dissemination of any arbitrary type of security research...

while it is a risk in all public disclosure of security research, only some types of research documents (generally actual malware) fail to give the security benefits when shared publicly that justify public disclosure... i may have agreed with the sentiment from mcafee that stealthkit disclosure shouldn't be afforded the same respect that normal full disclosure enjoys, but i think this case (that doesn't disclose actual malware but just research that malware creators might be able to use) legitimately falls under full disclosure... there are plenty of security benefits that can be had by examining the symbian OS...

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

FUD from bruce schneier

well, bruce schneier is at it again, spreading FUD about the anti-virus industry colluding with sony-bmg to prevent detection of their stealthkit (what passes for a rootkit these days)... and his kangaroo court readership buy it hook line and sinker, thinking the 'evidence' posted in the original thread was conclusive...

clearly people haven't actually read the original thead for meaning so i'm going to have to dissect the so-called evidence for them...

• f-secure, who's blacklight product was already detecting xcp (the sony/bmg stealthkit), admitted that they didn't immediately alert the public to the (low risk) threat because they knew the script kiddies would jump on the news of a large population of pre-compromized systems (and when the news came out that's exactly what happened) and were in talks with sony when mark russinovich broken the story... it's never been disclosed what those talks were about and it may seem like fun to assume the worst (collusion) but that's just the same paranoia that makes people want to believe anti-virus companies hire virus writers... there are far more reasonable possibilities, such as f-secure following responsible disclosure by trying to convince sony-bmg/first4internet to close the vulnerability in their stealthkit or possibly remove it altogether before releasing information about how the vulnerability could be exploited was released to the public (and scores of script kiddies)...
• norman's sandbox technology was also able to detect xcp before the news broke...
• symantec was implicated in the collusion through a claim that they had approved xcp but that claim was later explicitly corrected (link points to the exact google cache page pointed to in the aforementioned original thread)...
• multiple av companies downplayed the threat that xcp posed... again, one could be a conspiracy nut and believe it's because they were in on it, or one could be reasonable and recognize that it's quite normal for people to downplay the significance of their own failures...
• first4internet (the people who made xcp in the first place) apparently claimed to have worked with the big anti-virus companies to make sure their software was safe, but names were ultimately not given, and first4internet had their own arses to protect so there was plenty of motivation to try to fabricate vague legitimizing circumstances...

the so-called 'evidence' of collusion on the part of the anti-virus companies to avoid detecting xcp, to allow users' machines to become compromized undetectable, is evidence of nothing more than a peculiar desire not to trust anti-virus companies... there is no real evidence of collusion and bruce schneier's continued insistence that there is is nothing more than unmitigated FUD...

bruce schneier who claims to like the "be part of the solution, not part of the problem" metric is sowing fear, uncertainty, and doubt about an entire class of security company when he says things like:

You might have expected your antivirus software to detect Sony's rootkit. After all, that's why you bought it. But initially, the security programs sold by Symantec and others did not detect it, because Sony had asked them not to. You might have thought that the software you bought was working for you, but you would have been wrong.

and that can lead to people away from the only real tools there are for dealing with malware... that's certainly seems more like being part of the problem than part of the solution if you ask me...

of course, when he also says:

McAfee didn't add detection code until Nov. 9, and as of Nov. 15 it doesn't remove the rootkit, only the cloaking device.

he demonstrates that he's provably ignorant of the malware domain... under current parlance, the cloaking device IS the rootkit... under the more classical definition xcp was never a rootkit at all...

the security guru has a blind spot and that's malware, but people accept his word on the subject as security gospel - unable to apply basic logic and available facts to recognize when he's in error, unable to think for themselves... so who owns your opinions? you or some guy whose supposed to know about these things?

what's a stealthkit?

a stealthkit is a collection of one or more programs (a software toolkit -> a toolkit -> a kit) that hides the processes, data, and activity of itself and/or some other application(s) it may be packaged with...

a careful reader will notice that this is basically the same definition that much of the IT community is currently using for 'rootkits'... this is to distinguish this new type of malware from the classical form of rootkits... the nouveau 'rootkits' have a fundamentally different function and focus from the classical rootkits (even though classical rootkits were often also stealthkits) so creating a new term for them is reasonable... and there really isn't any reason to recycle an old term (rootkit) instead of coming up with a new term for something that is legitimately new - it's not like our word bag is empty...

normally i would never add my own terminology to a glossary, not even one on my own blog, but i have become so frustrated trying to keep track of whether i mean the new 'rootkit' or the classical rootkit when i say "rootkit" that i've decided i have to do this...

back to index

microsoft says escape from wet paper bag becoming impossible

holy crap, have you heard the news? microsoft has proclaimed that it's becoming impossible to recover from malware..

yeah, of course you've heard the news... everyone and their grandmother seems to think it's a big deal that microsoft is saying security is too hard...

microsoft is basically citing windows rootkits, advanced spyware, and anything else that might hook the kernal as the reason why recovery from malware is going to supposedly become impossible... in the malware world those things all boil down to stealth techniques, and as i've already said - we solved the stealth problem over a decade ago... microsoft, being deaf, blind, and monumentally stupid, made that solution basically unusable by foisting NTFS on us without giving us a solution for booting from a known clean removable medium and parsing NTFS partitions (before NTFS we could just boot from a write protected, bootable floppy disk and access the drive from DOS without triggering any malware self-defense mechanisms and without allowing the malware's stealth capabilities to be activated)...

the really weird thing is that microsoft does have the technology... it's called a PE (Preinstalled Environment) disk and not only does microsoft not want to give it away for free or bundle it with the operating system to aid in maintenance and disaster recovery, but they actually got on the case of the maker(s) of the BartPE disk (a free alternative to microsoft's own PE disk) a couple years ago, forcing the product temporarily offline...

lots of folks are taking microsoft's proclaimation seriously - don't buy into their cop-out... the handful of years they've spent trying to catch up in the security field are apparently just not enough for them to realize they have the solution in their own grubby little hands... the malware problem is not as bad as those morons in redmond make it out to be...

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]

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

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