i saw a lot of articles about the recent research done on the potential for malicious code injection and vote stealing on the diebold accuvote ts voting machines but there was one kind of article i was expecting but never saw...
you see, the researchers claimed to have created a virus for the voting machine as part of their research - so where's the outcry from the anti-virus community about that? there doesn't seem to be any (and i have web searches on virus/worm/trojan/{as many other malware terms as i can fit in a search query} redirected to my feed reader so i'm pretty sure i would have seen something if there was something to see) and that seems kind of peculiar when compared to the reaction to the consumer reports av tests...
what could be the cause of the silence? do they only care about virus creation when it serves as a handy way to deflect criticism that makes the vendor's product look bad? the fact that vendors whose products weren't tested by consumer reports also raised a stink about the virus creation, and the fact that the anti-virus-writing public letter most often cited was originally in reference to a university course that advertized virus writing as part of the curriculum, both suggest that the community's concern over virus writing is not as narrow and self-serving as the nay-sayers would have you believe...
maybe the security researchers involved in the voting machine virus creation are somehow beyond reproach? well, some people thought the security personalities involved in the consumer reports test were beyond reproach too, so that shouldn't be it either...
maybe the technical circumstances of the voting machine virus nullify the threat it poses? [sarcasm] because a virus that can only infect voting machines (that run windows) wouldn't really be a threat to the public if it fell into the wrong hands - it's just a threat to democracy... [/sarcasm]
well, i'll tell you what - i can't speak for anyone else in the anti-virus community, but if they're anything like me, maybe they just didn't know what to think at first, and as time wears on it becomes easier and easier to just let it go... when i first read the headlines i wasn't sure what to think - on a very basic level i felt uneasy about it but i wasn't sure if that was just a knee-jerk reaction so i waited for some anti-virus type who knows more than me to provide some analysis (or even an opinion) that would at least shed some light on how other people in the community felt about the whole thing... nothing doing though, so i've had to mull it over myself and i've come to the conclusion that my knee-jerk reaction was right...
the fundamental arguments against writing viruses for supposedly good reasons are a) there are inherent risks and social costs (unless you're able to ensure that no one ever finds out about it or encounters it) , and b) there ways to get the same results without creating a virus and thus without the problems in (a)... both of these apply in this case...
the risks are that the virus will fall into the wrong hands (either accidentally or on purpose) and affect people and as smart and trustworthy as the researchers may be, no one is above reproach (saints have been known to kill people), no one is beyond making errors... the risks remain no matter who is involved and the impact here could be dire, subverting the democratic process (even just for a single country) can a affect everyone... add to that the social costs of telling people who really have no business handling viruses let alone creating them that virus creation is a legitimate research practice... sure it might also embolden smart people to do good research too, but considering the persistent and autonomous nature of the threat that a self-replicating program poses (it can keep going and going long after anyone involved in it's creation or spread has lost interest and moved on) it really does only take a few bad apples to ruin the bunch...
that brings us to the issue of there being ways to get the same results, in this case being able to prove the same things, without creating a virus... i've already shown that this is possible in the general case and in this case in particular the researchers state quite clearly that the voting machines are general purpose computers (that makes viral susceptibility a forgone conclusion)... in fact they've made it clear that the machines run a version of windows, so there's absolutely no reason to create a virus for this platform since just about everyone knows that windows and viruses go together like peas and carrots... unless you want your new nickname to be 'captain obvious' there's no need to prove a virus is possible on this platform and so no need to create one for their security proof...
so if there was no need to create a virus, if you could demonstrate everything you needed to demonstrate with non-viral code (and you could), then the ends can not justify the means - the risks, however small they may be, remain present and the social costs are completely unmitigated... i don't want to bash the researchers too much (i do that an aweful lot) especially since there was a question (at least in my mind) about whether or not the ends might really justify the means in this particular virus-creation case (by gosh, democracy was at stake), but creating an actual virus (and by their description it was an actual virus, basically a kind of boot infector) was a wrong-headed thing to do...
Thursday, September 28, 2006
how to prove 'virus-ability' without creating a virus
let's say you're a security researcher and you're trying to demonstrate some security problem that involves viruses... it's relatively easy to write your deomonstration code as a non-replicating proof of concept exploit and simply say "this could easily be attached to a virus" and leave it at that - it's perfectly true that it could be attached to a virus, any function you like can be added to a computer virus, they're just programs after all...
that's all well and good if you're dealing with a normal desktop pc or some other platform for which we already know viruses are possible, but what if you're dealing with a system where viruses are as yet unheard of like an internet connected toaster, an assembly line robot, or an electronic voting machine? it may not be enough to just assume viruses are possible on such platforms, of course, because the proof you were trying to construct for the existence/feasability of whatever threat you were trying to demonstrate won't really be much of a proof anymore... you could try proving that the system in question satisfies the requirements of a general purpose computer, after all virus infectability is inherent to the general purpose computing platform, but that's probably going to go over most people's heads...
so try this instead: first show that you can introduce your own code into the system and get the system to execute it, then show that the code you introduce can write a secondary program (like a hello world program) to the systems storage memory and execute it... at this point you've proven self-replication is possible on the system, because if your main program can write a secondary program to the system's storage memory it can also write a copy of itself there...
now, let's say you want more than just basic self-replication, lets say file infection... have your main program do one of the following: write it's secondary program overtop of an existing host program on the system, rename an existing host program to something else and then give your secondary program the name the host program used to have, or change whatever pointer the system used to locate the existing host program so that it points to your new secondary program instead... you have now demonstrated the potential for file infection and so far have still not created a virus...
but wait, there's more - what if that's still not enough (and lets be honest, messing around with a single computer system doesn't really have the impact it used to), what if you need your hypothectical virus to spread to other systems over a network (a network worm)?... this too is relatively simple, instead of having your main program write a secondary program to the local computer's storage memory, have it send the secondary program to a second system along with whatever tricks you need to get the second system to execut it... this demonstrates network spreading because your main program could have just as easily sent a copy of itself rather than a dummy program.... and if you want it to have some real visual appeal, make your hello world program print "i'm infected" instead of "hello world"...
at this point you'll have demonstrated all of the viral characteristics that would be necessary for your larger security proof without actually writing a virus, therefore making the writing of viruses for security proofs (even security proofs for computing platforms for which real viruses are unheard of) unnecessary...
that's all well and good if you're dealing with a normal desktop pc or some other platform for which we already know viruses are possible, but what if you're dealing with a system where viruses are as yet unheard of like an internet connected toaster, an assembly line robot, or an electronic voting machine? it may not be enough to just assume viruses are possible on such platforms, of course, because the proof you were trying to construct for the existence/feasability of whatever threat you were trying to demonstrate won't really be much of a proof anymore... you could try proving that the system in question satisfies the requirements of a general purpose computer, after all virus infectability is inherent to the general purpose computing platform, but that's probably going to go over most people's heads...
so try this instead: first show that you can introduce your own code into the system and get the system to execute it, then show that the code you introduce can write a secondary program (like a hello world program) to the systems storage memory and execute it... at this point you've proven self-replication is possible on the system, because if your main program can write a secondary program to the system's storage memory it can also write a copy of itself there...
now, let's say you want more than just basic self-replication, lets say file infection... have your main program do one of the following: write it's secondary program overtop of an existing host program on the system, rename an existing host program to something else and then give your secondary program the name the host program used to have, or change whatever pointer the system used to locate the existing host program so that it points to your new secondary program instead... you have now demonstrated the potential for file infection and so far have still not created a virus...
but wait, there's more - what if that's still not enough (and lets be honest, messing around with a single computer system doesn't really have the impact it used to), what if you need your hypothectical virus to spread to other systems over a network (a network worm)?... this too is relatively simple, instead of having your main program write a secondary program to the local computer's storage memory, have it send the secondary program to a second system along with whatever tricks you need to get the second system to execut it... this demonstrates network spreading because your main program could have just as easily sent a copy of itself rather than a dummy program.... and if you want it to have some real visual appeal, make your hello world program print "i'm infected" instead of "hello world"...
at this point you'll have demonstrated all of the viral characteristics that would be necessary for your larger security proof without actually writing a virus, therefore making the writing of viruses for security proofs (even security proofs for computing platforms for which real viruses are unheard of) unnecessary...
Saturday, September 23, 2006
ZERT's 3rd party VML patch
ZERT, short for zero-day emergency response team, have released a patch for the microsoft VML vulnerability that has been recently uncovered and exploited...
there have been 3rd party patches in the past (the WMF one being a prime example) but the significance here is that an organization has formed (with an impressive set of members) specifically for the purpose of releasing 3rd party patches to vulnerabilities that are exploited before a patch is available from the vulnerable software's vendor...
i've mentioned 3rd party patches before and why they're needed (because certain vendors don't do enough to shut the window of exposure quickly enough)... i thought they were a good idea and i think they're an even better idea now... rumor has it that microsoft may release a patch for the VML vulnerability out of cycle (before the 2nd tuesday of next month) but this rumor only seems to have surfaced after ZERT released their 3rd party patch... furthermore, another rumor has it that microsoft was/is considering releasing an early patch for their onecare customers (which just goes to show what i said before about their being no moral high ground for microsoft in the security industry is proving moot because they clearly have no interest in the moral high ground)... i have no idea if the 2 rumors are related, but regardless of that it seems to me that 3rd party patches may serve to help keep microsoft honest in a way that full disclosure was supposed to do...
i can't mention ZERT's VML patch without drawing attention to what randy abrams has written about it, though... in spite of being a member of ZERT, he wisely posts words of caution over the use of their 3rd party patch that basically boil down to this: most people don't need or use VML in the first place and so the existing workaround of disabling it is a better option than the 3rd party patch under those circumstances - you should only need the 3rd party patch if you really need the vector graphics (not just regular graphics, mind you) rendering engine to operate, and then you should only need the 3rd party patch until the vendor releases their own patch... that's good advice and i think it can probably be applied to 3rd party patches in general, not just this one...
there have been 3rd party patches in the past (the WMF one being a prime example) but the significance here is that an organization has formed (with an impressive set of members) specifically for the purpose of releasing 3rd party patches to vulnerabilities that are exploited before a patch is available from the vulnerable software's vendor...
i've mentioned 3rd party patches before and why they're needed (because certain vendors don't do enough to shut the window of exposure quickly enough)... i thought they were a good idea and i think they're an even better idea now... rumor has it that microsoft may release a patch for the VML vulnerability out of cycle (before the 2nd tuesday of next month) but this rumor only seems to have surfaced after ZERT released their 3rd party patch... furthermore, another rumor has it that microsoft was/is considering releasing an early patch for their onecare customers (which just goes to show what i said before about their being no moral high ground for microsoft in the security industry is proving moot because they clearly have no interest in the moral high ground)... i have no idea if the 2 rumors are related, but regardless of that it seems to me that 3rd party patches may serve to help keep microsoft honest in a way that full disclosure was supposed to do...
i can't mention ZERT's VML patch without drawing attention to what randy abrams has written about it, though... in spite of being a member of ZERT, he wisely posts words of caution over the use of their 3rd party patch that basically boil down to this: most people don't need or use VML in the first place and so the existing workaround of disabling it is a better option than the 3rd party patch under those circumstances - you should only need the 3rd party patch if you really need the vector graphics (not just regular graphics, mind you) rendering engine to operate, and then you should only need the 3rd party patch until the vendor releases their own patch... that's good advice and i think it can probably be applied to 3rd party patches in general, not just this one...
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...
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...
Wednesday, September 20, 2006
symantec and the poor man's 'rootkit'
can't we stop calling everything a rootkit? please?
i grow weary of pointing out terminology misuse over and over again - from stealth digital rights malware, to protected recycle bins, to anti-virus products, to alternate data streams (yes, ADS all by itself has been likened to a 'rootkit') - but if someone sinks to a new low, well the full range of this terminology abuse needs to be documented in order to underscore how idiotic it is...
the latest 'new low' comes from symantec where the 'rootkit' label is being (loosely) applied to a trojan that scans through the registry for programs that get run and then replaces one (or more?) of them with a copy of itself while saving a backup of the original to execute after the trojan gets executed...
so apparently now trojans that employ the non-viral equivalent of companion file infection are 'rootkits'... well gee, at that rate just about any kind of program paracitism (i hesitate to call it file infection as i reserve infection for self-replicators) is a 'rootkit' technique since just about all of them hide changes as well as or even better than companion infectors (overwriting infectors are about the only kind that does a worse job)... so nearly all file infecting viruses and other forms of paracitic malware are 'rootkits' - yeah, that's a wonderful message to be sending people who look to you for expert analysis, symantec... thanks a lot...
things weren't bad enough when virus was treated as an umbrella term, or when spyware became the new umbrella term, now it's going to be 'rootkit'... let's take this absurd "if it hides things it's a rootkit" business to it's logical conclusion, shall we? file permissions are a 'rootkit' technique, attrib is a 'rootkit', popups are 'rootkits', the cursor is a micro-'rootkit' - my trousers are a 'rootkit'...
i grow weary of pointing out terminology misuse over and over again - from stealth digital rights malware, to protected recycle bins, to anti-virus products, to alternate data streams (yes, ADS all by itself has been likened to a 'rootkit') - but if someone sinks to a new low, well the full range of this terminology abuse needs to be documented in order to underscore how idiotic it is...
the latest 'new low' comes from symantec where the 'rootkit' label is being (loosely) applied to a trojan that scans through the registry for programs that get run and then replaces one (or more?) of them with a copy of itself while saving a backup of the original to execute after the trojan gets executed...
so apparently now trojans that employ the non-viral equivalent of companion file infection are 'rootkits'... well gee, at that rate just about any kind of program paracitism (i hesitate to call it file infection as i reserve infection for self-replicators) is a 'rootkit' technique since just about all of them hide changes as well as or even better than companion infectors (overwriting infectors are about the only kind that does a worse job)... so nearly all file infecting viruses and other forms of paracitic malware are 'rootkits' - yeah, that's a wonderful message to be sending people who look to you for expert analysis, symantec... thanks a lot...
things weren't bad enough when virus was treated as an umbrella term, or when spyware became the new umbrella term, now it's going to be 'rootkit'... let's take this absurd "if it hides things it's a rootkit" business to it's logical conclusion, shall we? file permissions are a 'rootkit' technique, attrib is a 'rootkit', popups are 'rootkits', the cursor is a micro-'rootkit' - my trousers are a 'rootkit'...
Monday, September 11, 2006
eicar-standard-anti-malware-test-file
ok, so i was either really early or a little late in saying something about the eicar standard anti-virus test file being repurposed for more general anti-malware usage...
this isn't an i told you so . . . ok, maybe just a little... but c'mon, it's not like this was ever rocket science... spycar, supposedly an homage to eicar, was never necessary to test if anti-spyware apps were installed properly when the eicar file was just as good for that purpose... and as i stated before, for any other sort of testing as spyware simulators really only tells you if your anti-spyware app can detect simulated spyware (and by simulated, i mean a rather poor simulation at that as none of it seems particularly targeted to any unique property of spyware)... i knew it was going to be misused in testing (just as virus simulators were and sometimes still are misused in anti-virus testing), which is why i said that good spyware simulators were still a bad idea, and of course i was proven right...
so, now that spycar is obsolete and the eicar test file (you can't just call it eicar, by the way, since that's the european institute for computer anti-virus research) has been renamed (the file itself remains unchanged, though, just in case that wasn't clear to everyone) so as to be used to test that anti-spyware (and other anti-malware) scanners are installed and operating properly (there's just no good way to test that for behaviour-based systems without real malware), maybe now we can put the whole 'lets make a new testfile for our new anti-[something-or-other] industry' notion to bed once and for all... yeah, and maybe i'll find the pot of gold at the end of a rainbow...
this isn't an i told you so . . . ok, maybe just a little... but c'mon, it's not like this was ever rocket science... spycar, supposedly an homage to eicar, was never necessary to test if anti-spyware apps were installed properly when the eicar file was just as good for that purpose... and as i stated before, for any other sort of testing as spyware simulators really only tells you if your anti-spyware app can detect simulated spyware (and by simulated, i mean a rather poor simulation at that as none of it seems particularly targeted to any unique property of spyware)... i knew it was going to be misused in testing (just as virus simulators were and sometimes still are misused in anti-virus testing), which is why i said that good spyware simulators were still a bad idea, and of course i was proven right...
so, now that spycar is obsolete and the eicar test file (you can't just call it eicar, by the way, since that's the european institute for computer anti-virus research) has been renamed (the file itself remains unchanged, though, just in case that wasn't clear to everyone) so as to be used to test that anti-spyware (and other anti-malware) scanners are installed and operating properly (there's just no good way to test that for behaviour-based systems without real malware), maybe now we can put the whole 'lets make a new testfile for our new anti-[something-or-other] industry' notion to bed once and for all... yeah, and maybe i'll find the pot of gold at the end of a rainbow...
administrivia
just a quick note for those who've subscribed to the feed, i recently switched to the new blogger beta and that seems to have caused some wierdness with regards to the feed (you might have seen the last 25 posts show up as new because they all got republished in the process of the migration)... sorry for that, hopefully that won't happen again (at least not on that scale, can't promise i won't edit things when i spot an error)...
Saturday, September 02, 2006
the end of security experts
no, i'm not talking about some sort of apocalypse that's going to wipe out all the security experts, i'm talking about the fact that the very notion of a security expert is starting to become ridiculous...
what's brought this line of thinking on is the raging false authority syndrome being displayed in the security community over the recent consumer reports contraversy... everywhere i look i'm finding so-called security experts offering their opinions about how the anti-virus community is overreacting or people citing security experts when discussing virus related issues...
i have a computer science degree, does that make me an expert in (or qualified in any way to talk about) artificial intelligence? no... sure AI research is a computer science discipline but my computer science background was not in AI... in fact there are a number of computer science disciplines which are so far outside of my experience that i know better than to open my mouth about them most of the time... too bad this doesn't hold true for the computer security community...
see, the security domain is not a simple one and it's not getting any simpler as time goes by... it's a complex and diverse set of quasi-related fields and specialized disciplines and the reality is that it's no longer possible (and hasn't been for some time) for any one person to have expert knowledge of them all... so what we have instead of security experts are experts in some specialized security subdisciplines with good heads for a lot of the more generic security concepts... they call themselves (or are called by others) security experts but that's not really what they are, and the knowledge from their own particular area of expertise is not necessarily applicable to all other parts of the computer security domain...
that doesn't stop them, however, as the consumer reports contraversy clearly illustrated... anti-malware in general and anti-virus in particular is a highly specialized discipline that deals with a kind of threat unlike anything else currently in the computer security domain... unfortunately we still have security experts saying viruses artificially generated in a lab represent the real world more accurately than viruses from the real world, or likening the threat posed by viruses to the threat posed by remote code execution exploits, or that the only reason the anti-virus companies reacted the way they did was because consumer reports made their products look bad (in spite of the fact that retrospective testing does the same thing, or the fact that some of the companies complaining weren't even included in the consumer reports test), etc...
if these people have no real background in the anti-virus field, why should what they say about virus issues be given any weight above that of a novice? because they're security experts and the anti-virus field is part of the security domain? please - security experts are not experts in all the security related disciplines, usually only one or two... most don't even bother to get enough of a taste of the other disciplines outside their area of expertise to know the true extent to which their own knowledge can apply there, otherwise they wouldn't behave like authorities on subjects for which they quite obviously have no real qualifications - the epitome of false authority syndrome... most security experts have no appreciation for the limitations that computational complexity places on detection techniques, or for the autonomous nature of the threat, or the environmental conditions that caused the anti-virus community to evolve the way it has, or any of a myriad of other details that are required to be a true authority in the anti-virus field...
the title of security expert is dead, it just doesn't know it yet... it doesn't mean what people think it means anymore, it's just a way of putting on airs... next time someone gets called or calls themself a security expert ask yourself "is that like an animal expert?" and then ask yourself if you have a question about a particular type of insect, do you want to talk to an animal expert or an entomologist?...
what's brought this line of thinking on is the raging false authority syndrome being displayed in the security community over the recent consumer reports contraversy... everywhere i look i'm finding so-called security experts offering their opinions about how the anti-virus community is overreacting or people citing security experts when discussing virus related issues...
i have a computer science degree, does that make me an expert in (or qualified in any way to talk about) artificial intelligence? no... sure AI research is a computer science discipline but my computer science background was not in AI... in fact there are a number of computer science disciplines which are so far outside of my experience that i know better than to open my mouth about them most of the time... too bad this doesn't hold true for the computer security community...
see, the security domain is not a simple one and it's not getting any simpler as time goes by... it's a complex and diverse set of quasi-related fields and specialized disciplines and the reality is that it's no longer possible (and hasn't been for some time) for any one person to have expert knowledge of them all... so what we have instead of security experts are experts in some specialized security subdisciplines with good heads for a lot of the more generic security concepts... they call themselves (or are called by others) security experts but that's not really what they are, and the knowledge from their own particular area of expertise is not necessarily applicable to all other parts of the computer security domain...
that doesn't stop them, however, as the consumer reports contraversy clearly illustrated... anti-malware in general and anti-virus in particular is a highly specialized discipline that deals with a kind of threat unlike anything else currently in the computer security domain... unfortunately we still have security experts saying viruses artificially generated in a lab represent the real world more accurately than viruses from the real world, or likening the threat posed by viruses to the threat posed by remote code execution exploits, or that the only reason the anti-virus companies reacted the way they did was because consumer reports made their products look bad (in spite of the fact that retrospective testing does the same thing, or the fact that some of the companies complaining weren't even included in the consumer reports test), etc...
if these people have no real background in the anti-virus field, why should what they say about virus issues be given any weight above that of a novice? because they're security experts and the anti-virus field is part of the security domain? please - security experts are not experts in all the security related disciplines, usually only one or two... most don't even bother to get enough of a taste of the other disciplines outside their area of expertise to know the true extent to which their own knowledge can apply there, otherwise they wouldn't behave like authorities on subjects for which they quite obviously have no real qualifications - the epitome of false authority syndrome... most security experts have no appreciation for the limitations that computational complexity places on detection techniques, or for the autonomous nature of the threat, or the environmental conditions that caused the anti-virus community to evolve the way it has, or any of a myriad of other details that are required to be a true authority in the anti-virus field...
the title of security expert is dead, it just doesn't know it yet... it doesn't mean what people think it means anymore, it's just a way of putting on airs... next time someone gets called or calls themself a security expert ask yourself "is that like an animal expert?" and then ask yourself if you have a question about a particular type of insect, do you want to talk to an animal expert or an entomologist?...
Subscribe to:
Posts (Atom)