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]
devising a framework for thinking about malware and related issues such as viruses, spyware, worms, rootkits, drm, trojans, botnets, keyloggers, droppers, downloaders, rats, adware, spam, stealth, fud, snake oil, and hype...
Thursday, June 29, 2006
Wednesday, June 28, 2006
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...
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...
Tags:
blue pill,
joanna rutkowska,
malware,
rootkit,
stealth,
stealthkit,
virtualization
Tuesday, June 13, 2006
surprised by malicious software removal tool statistics
if you follow such things, i'm sure you've seen quite a few posts about microsoft's new malicious software removal tool study...
of course some folks can't manage to properly interpret the stats in it, prompting microsoft to issue a clarification (they did not find bots on ~60% of all computers scanned, only on ~60% of computers they cleaned), but i can sort of see where those people are coming from... we've sort of become accustomed to the idea that malware really is that prevalent - that's certainly the message the media has been pushing for a long time... microsoft's study is saying something very different, however:
now, i imagine if microsoft agreed to add detection/removal for their own spyware the percentage would be much higher so there might arguably be an issue of malware prevalence being under reported in order to allow practices that would result in most other supposed security vendors being labelled rogue...
another reason to suspect under reporting is that microsoft is complaining about the difficulty of dealing with tens of thousands of peices of malware when the anti-virus industry has been dealing with hundreds of thousands of peices of malware for some time now:
i don't know, maybe microsoft's numbers are right... there's not a lot to compare them to - i haven't really seen similar types of metrics coming out of other vendors for the most part (probably because most vendors' products don't report their results back to their creator(s) ... and why does microsoft's do that again?)...
if the numbers are right, it certain adds a new perspective on things... but as with all statistics it needs to be taken with a grain of salt...
of course some folks can't manage to properly interpret the stats in it, prompting microsoft to issue a clarification (they did not find bots on ~60% of all computers scanned, only on ~60% of computers they cleaned), but i can sort of see where those people are coming from... we've sort of become accustomed to the idea that malware really is that prevalent - that's certainly the message the media has been pushing for a long time... microsoft's study is saying something very different, however:
As of the writing of this report, Microsoft has shipped 15 additional enhanced versions of the tool and continues to ship a new version on the second Tuesday of each month, each adding new prevalent malware to detect and remove. Since the initial release of the MSRT, the tool has been executed approximately 2.7 billion times by at least 270 million unique computers....
in 15 months of operation they've scanned ~270 million unique computers and removed malware from only 5.7 million?... that's just 2.1%... that seems surprisingly low to me...
The MSRT has removed 16 million instances of malicious software from 5.7 million unique Windows-based computers over the past 15 months. On average, the tool removes at least one instance of malware from every 311 computers it runs on.
now, i imagine if microsoft agreed to add detection/removal for their own spyware the percentage would be much higher so there might arguably be an issue of malware prevalence being under reported in order to allow practices that would result in most other supposed security vendors being labelled rogue...
another reason to suspect under reporting is that microsoft is complaining about the difficulty of dealing with tens of thousands of peices of malware when the anti-virus industry has been dealing with hundreds of thousands of peices of malware for some time now:
A significant challenge we have today is the large number of active malware samples, totaling in the order of tens of thousands, and increasing rapidly.
i don't know, maybe microsoft's numbers are right... there's not a lot to compare them to - i haven't really seen similar types of metrics coming out of other vendors for the most part (probably because most vendors' products don't report their results back to their creator(s) ... and why does microsoft's do that again?)...
if the numbers are right, it certain adds a new perspective on things... but as with all statistics it needs to be taken with a grain of salt...
Friday, June 09, 2006
can joe barr's opinion of the malware industry be trusted?
well, joe barr is at it again... i've blogged about joe once before and where the previous article i wrote about seemed to just be a case of false authority syndrome, this new one about whether the anti-malware industry can be trusted seems to be a more deliberate smear campaign...
when he's not throwing out non-sequiturs like what happened to dan greer formerly of @stake (which isn't really part of the anti-malware industry), he's redressing other non-sequiturs to look like they're actually relevant... for example:
then there's innuendo about timing things specifically to make OSX look bad:
there's some crazy re-interpreting of that same report, too:
the real meat of the article doesn't come until the section entitled "From Russia with malice", however... joe barr clearly has a venomous contempt for kaspersky labs, he goes on and on about supposed wrong-doings, such as:
of course, since he was chronicling all the perceived misdeeds of kaspersky he had to include 'the case of the non-viral virus' that i de-debunked previously, but then he goes on to describe his disbelief over their linux malware report that showed there were 91 viruses for the linux platform:
his final bit of evidence against kaspersky came from the recently noted intended macro virus which caused the confusion i wrote about earlier:
joe barr concludes that the anti-malware industry cannot be trusted and he attributes all these misdeeds to a desire for more money - so what should we attribute joe barr's misdeeds (ie. his FUD) to?
when he's not throwing out non-sequiturs like what happened to dan greer formerly of @stake (which isn't really part of the anti-malware industry), he's redressing other non-sequiturs to look like they're actually relevant... for example:
US-Cert knows about the problem of the super-inflated malware numbers in their summary,except that cert doesn't count malware, they count vulnerabilities - ergo what cert is or isn't doing, what they do or don't know has no bearing on whether the anti-malware industry can be trusted...
then there's innuendo about timing things specifically to make OSX look bad:
The SANS Institute, -- a name which sounds all officious and possibly not profit oriented, but which is owned by the mysterious but definitely for-profit Escal Institute of Technology -- recently did an unusual update to its Top 20 list of vulnerabilities.what mr.barr fails to acknowledge, however, is that there's a 3rd event in this coincidence - that being the dramatic change in the security landscape of OSX around the same time... 2 viruses and a spate serious vulnerabilities - issuing a report to inform people of the new state of things was a responsible thing for SANS to do...
They issued their "update" in order to trumpet the assertion that Apple OS X is now just as exposed and vulnerable to malware as Windows. The timing of the release of this unusual "update" is suspicious, coming as it did on the eve of the new advertising campaign by Apple which plays up the fact that Apple is pretty much immune to the types of malware infestations that plague Windows. Previous updates to this list have usually come in the fall: November, 2005; October, 2004; October, 2003; and October, 2002.
there's some crazy re-interpreting of that same report, too:
The SANS Institute announcement seemed to be designed to destroy -- or at least bring into question -- the idea that Apple OS X is more secure than Windows. In a document sent to members of the press prior to the teleconference, the SANS Institute wrote:now, how exactly can the report destroy or bring into question the idea that OSX is more secure than windows when his own quote of the report explicitly says that OSX is still safer than windows? and his later jab (by way of quoting a 3rd party) at the supposed claim that OSX's security reputation is in tatters? the quote clearly shows that the report said OSX's reputation for being bullet-proof was in tatters - which it is... it can't be considered bullet-proof anymore, it's been proven that it's not totally immune to threats...During the past few months, Apple Safari browser users faced their first zero-day attack. A zero-day attack is one that causes damage to users even before the vendor makes a patch available. In this case, Safari users who just browsed a malicious web site found their computers automatically downloading and executing a malicious file. The user made no error other than to visit the web site. Apple patched Safari to fix this flaw, but almost immediately had to issue a second patch to stop another attack involving email attachments. The experts involved in the 2006 Top 20 Spring update agree that OS/X still remains safer than Windows; but its reputation for offering a bullet-proof alternative to Windows is in tatters. As attackers are increasingly turning their attention to the platform, OS/X vulnerabilities are being discovered at a rapid pace, which could erode this safety in the future.
the real meat of the article doesn't come until the section entitled "From Russia with malice", however... joe barr clearly has a venomous contempt for kaspersky labs, he goes on and on about supposed wrong-doings, such as:
Kaspersky Lab, a Russian Internet security company which operates around the globe, including here in the USA, has been spreading FUD about malware targeting Linux for years. I've cited this example from 2001 before, but here it is again, and it still appears on their Web site. Hey, maybe the SANS Institute used it as a template for their anti-Apple effort. I quote:while one would probably not consider ramen going into the wild to be comparable with the windows worm epidemics like blaster or sasser, compared with other linux malware it was a very big deal... as for pelf, cross-platform infectors have long been considered the means by which self-replicating linux malware would become really widespread and pelf was an indication that such infectors were coming...Predictions regarding a world epidemic of Linux-viruses have come true in the first quarter of 2001. The latest incidents caused by the Ramen Internet-worm and its numerous modifications, as well as the multi-platform virus Pelf (Lindose) and other Linux-targeted malicious code, have proved that this operating system, (previously considered as the most protected software), has fallen victim to computer viruses.
of course, since he was chronicling all the perceived misdeeds of kaspersky he had to include 'the case of the non-viral virus' that i de-debunked previously, but then he goes on to describe his disbelief over their linux malware report that showed there were 91 viruses for the linux platform:
I asked Kaspersky Lab if they had any documentation to back up that claim. Jennifer Jewett, a public relations person representing Kaspersky, told me "the documentation sighting the viruses is included in the Encyclopedia on Kaspersky's Viruslist site: http://www.viruslist.com/en/viruses/encyclopedia."strangely, when i did a search for linux viruses on that site, i got 92 hits not 972... just one more than was indicated in the report - most without actual descriptions but at least they include the aliases that other products use so that one can corroborate their existence... is he incapable of using a search engine or just so biased against kaspersky that he can't manage due dilligence? he knew the result set shouldn't have been anywhere near that big, he should have refined his search to narrow it down to just viruses (972 would have been the list of all linux malware, not just viruses, though the number now stands at 976 and will probably change again as time wears on)...
I searched the encyclopedia for Linux viruses and came up with an astounding 972 hits. But just the barest hint of an analysis of those hits reveal that the number would break an industrial-strength bogusity-meter.
his final bit of evidence against kaspersky came from the recently noted intended macro virus which caused the confusion i wrote about earlier:
After this story was submitted, and the week following another black-eye for Microsoft security in the form of malevolent macros in MS Word, Kaspersky Lab issued another headline-grabbing but bogus alert for a proof-of-concept of the same type of attack on MS Word's largest competitor, OpenOffice.org. Was the timing once more just a coincidence? I don't think so.since the existence of the malware was independently confirmed and since kaspersky labs didn't create it themselves, the timing was entirely out of their hands... it gets discovered when it gets discovered... should they have kept the first openoffice malware a secret? would it have really served the public to sit on the fact that openoffice is now being targeted by at least one malware writer? somehow that doesn't seem likely...
joe barr concludes that the anti-malware industry cannot be trusted and he attributes all these misdeeds to a desire for more money - so what should we attribute joe barr's misdeeds (ie. his FUD) to?
Tags:
anti-malware,
fud,
joe barr
Thursday, June 08, 2006
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...
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...
Tags:
cellphone,
full disclosure,
mcafee,
rootkit,
stealthkit,
symbian
Wednesday, June 07, 2006
the stardust dustup
i've been seeing a number of posts like this lately, talking about how the new staroffice/openoffice macro virus is just hype...
statements like this are really telling:
there's lots of talk about how kaspersky labs is misleading the public and hyping up a non-existent threat... about how nothing in stardust is really new and how it's not really a vulnerability but rather a misuse of legitimate functionality... well, here's the thing:
statements like this are really telling:
In a statement prominently displayed on the OpenOffice.org home page, the group also disputes applying the label “virus” to Stardust, the proof-of-concept exploit discovered last week by Kaspersky Labs.you see, stardust is an intended virus as mentioned by both mcafee and kaspersky... unfortunately, kaspersky labs didn't mention it was broken in their first blog post on it, only in the actual encyclopedia description which the media (mainstream and blogosphere alike) didn't bother to read and/or understand, thus necessitating the second blog post to clarify the issue...
there's lots of talk about how kaspersky labs is misleading the public and hyping up a non-existent threat... about how nothing in stardust is really new and how it's not really a vulnerability but rather a misuse of legitimate functionality... well, here's the thing:
- while it's true kasperky labs could have made a more informative blog post the first time 'round, the place where they said further details would be clearly stated the virus was broken...
- what's new here is that someone is trying to write viruses for the staroffice/openoffice platform and they may eventually succeed or someone else may fix the bugs in the current attempts and thereby succeed in making a virus for that platform... stardust is the first attempt, and the fact that someone is making that attempt is new and newsworthy... there might not be an actual virus yet, but one (or more) is coming...
- of course it's just a misuse of legitimate functionality - that's true for viruses in general... they aren't made possible only because of security defects, they're inherent to the general purpose computing platform and if you're going to provide a reasonably powerful macro programming facility in your office suite you're going to invariably wind up supporting macro viruses...
Tags:
kaspersky,
macro virus,
malware,
openoffice,
stardust,
staroffice
what is a macro virus?
a macro virus is a virus written in a macro programming language (a programming language for embedding simple programs within documents)...
most (but not all) macro viruses are written to operate in microsoft applications such as word or excel or powerpoint... these macro viruses contain one or more macros with the same name as a macro that is built into the microsoft application they're running under... then, when the ms application tries to execute it's own macro it finds the one in the document first and executes it (which makes it kind of like a companion infection technique)... since the applications in question have macros for all kinds of standard functions (like file->save or file->open) macro viruses don't have any trouble getting executed...
although it is often said that macro viruses infect documents this does not mean it's a type of virus that infects data... for one thing word/excel/powerpoint (OLE2) documents are not pure data - they're more like little file systems that contain both data and (macro) programs, not unlike your C: drive... so when someone says "my document is infected with a virus" it's comparable to the colloquialism "my computer is infected with a virus"... also, technically what a macro virus is infecting is another macro...
additionally, the operating system that uses those little file systems is the ms application that opens the document - that's why macro viruses can often operate on both windows and macs without being classified cross-platform... whether it's a windows machine or a mac machine a word macro virus runs on the ms word platform...
back to index
most (but not all) macro viruses are written to operate in microsoft applications such as word or excel or powerpoint... these macro viruses contain one or more macros with the same name as a macro that is built into the microsoft application they're running under... then, when the ms application tries to execute it's own macro it finds the one in the document first and executes it (which makes it kind of like a companion infection technique)... since the applications in question have macros for all kinds of standard functions (like file->save or file->open) macro viruses don't have any trouble getting executed...
although it is often said that macro viruses infect documents this does not mean it's a type of virus that infects data... for one thing word/excel/powerpoint (OLE2) documents are not pure data - they're more like little file systems that contain both data and (macro) programs, not unlike your C: drive... so when someone says "my document is infected with a virus" it's comparable to the colloquialism "my computer is infected with a virus"... also, technically what a macro virus is infecting is another macro...
additionally, the operating system that uses those little file systems is the ms application that opens the document - that's why macro viruses can often operate on both windows and macs without being classified cross-platform... whether it's a windows machine or a mac machine a word macro virus runs on the ms word platform...
back to index
Tags:
definition,
macro virus,
malware
Tuesday, June 06, 2006
what is a companion virus?
a companion virus is a virus that exists as a separate (companion) program to the host program...
it may not be obvious how something like this would be able to meet the definine criteria of a virus and may sound more like a worm, however a companion virus is able to infect host programs without modifying their contents (that is how they can be separate programs)... it does this by taking advantage of operating system features that allow it to be executed instead of it's host program...
for example - in DOS if you type a program name without specifying the path and that program happens to not be in the current directory, DOS will search each directory in your PATH sequentially until it finds a program with that name or it reaches the end of your PATH... a path companion virus need only assume the same name as an existing program on your computer but place itself in a directory closer to the beginning of your PATH so that DOS finds the viral program first and executes it instead of the program the user intended...
another type of companion infection utilizes the fact that if a program name is specified without a file extension, DOS will look for *.com files before it looks for *.exe files so the virus need only copy itself as ProgramName.com in the same directory as the original ProgramName.exe in order to get executed...
some flavours of *nix (as well as some alternative DOS shells) have a command alias facility that can also be used for companion infection...
additionally, a virus could rename or make a backup copy of the host program and then replace the original with itself and be yet another kind of companion virus...
the original program is generally retained so that the companion virus can execute it after the virus itself gets executed - this makes the system appear to behave properly since the program you intended to execute does get executed....
back to index
it may not be obvious how something like this would be able to meet the definine criteria of a virus and may sound more like a worm, however a companion virus is able to infect host programs without modifying their contents (that is how they can be separate programs)... it does this by taking advantage of operating system features that allow it to be executed instead of it's host program...
for example - in DOS if you type a program name without specifying the path and that program happens to not be in the current directory, DOS will search each directory in your PATH sequentially until it finds a program with that name or it reaches the end of your PATH... a path companion virus need only assume the same name as an existing program on your computer but place itself in a directory closer to the beginning of your PATH so that DOS finds the viral program first and executes it instead of the program the user intended...
another type of companion infection utilizes the fact that if a program name is specified without a file extension, DOS will look for *.com files before it looks for *.exe files so the virus need only copy itself as ProgramName.com in the same directory as the original ProgramName.exe in order to get executed...
some flavours of *nix (as well as some alternative DOS shells) have a command alias facility that can also be used for companion infection...
additionally, a virus could rename or make a backup copy of the host program and then replace the original with itself and be yet another kind of companion virus...
the original program is generally retained so that the companion virus can execute it after the virus itself gets executed - this makes the system appear to behave properly since the program you intended to execute does get executed....
back to index
Tags:
companion virus,
definition,
malware
what are intended viruses?
an intended virus (or sometimes just intended) is a piece of malware that would have been a virus were it not for bugs that prevent it from fulfilling the basic requirements of a virus... in other words, it's something that would have been a virus if it weren't broken...
an intended may have a payload that may still work (to a greater or lesser degree) so it may still qualify as some other form of malware, such as a trojan or rat or keylogger or any number of other malware types...
additionally, although the current version is only an intended virus, a future version will probably be a real virus because viruses tend to get refined over time...
back to index
an intended may have a payload that may still work (to a greater or lesser degree) so it may still qualify as some other form of malware, such as a trojan or rat or keylogger or any number of other malware types...
additionally, although the current version is only an intended virus, a future version will probably be a real virus because viruses tend to get refined over time...
back to index
Tags:
definition,
intended virus,
malware
Sunday, June 04, 2006
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:
he goes on to say:
some of the things he's written are just wacky, like:
another off the wall statement is the following:
hiding things is an ethical issue, and he recognizes that when he writes:
he ends off with:
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...
Tags:
greg hoglund,
malware,
rootkit,
stealthkit
Subscribe to:
Posts (Atom)