when it's pwned by someone else...
it fell into someone else's hands just last month but at least that time the new registrar seemed cooperative and gave it back to the rightful owners...
now, unfortunately, the current content seems to indicate that the blog has turned into a splog or worse considering how these things tend to go...
as such it looks like the infosec sellout blog is unsafe again... guess they just can't catch a break...
Wednesday, August 15, 2007
Friday, August 10, 2007
what is server-side polymorphism?
server-side polymorphism is a type of polymorphism where the polymorphic engine (the transformation function responsible for producing the malware's many forms) doesn't reside within the malware itself...
just as conventional polymorphism was constrained to housing the polymorphic engine within the virus its meant to operate on (because the code doing the copying has to have access to the transformation function), server-side polymorphism requires the polymorphic engine to be part of the system (generally a website) that serves (hands out) copies of the non-replicative malware it's used on instead of being in the malware itself...
this has proven to be very effective and very hard to counter from a conventional known-malware perspective... the reason is because with the polymorphic engine staying on the server instead of residing within the malware itself the transformation function can remain unknown to the malware analysts... although the analysts can try to perform black-box analysis of the transformation function, without knowing all the variables the function takes into account it's not possible to model the entire algorithm and predict all possible outputs... further, the transformation function can be arbitrarily complex, it could involve actually recompiling the malware with different parameters, or it might not even be an algorithm at all (someone might literally be manually changing the malware that the server is handing out)...
given this, it's not really possible in the general case for signature-based known-malware detection technology to reliably detect all instances of a piece of malware that employs server-side polymorphism but there are some facts that anti-malware vendors can use to their advantage... first, while signatures probably won't work, heuristics should be able to have some success against the various instances of such malware (assuming the polymorphism isn't too complex)... second, polymorphism has never been easy to develop and so the use (and sale) of kits may be helpful since the kits should contain the polymorphic engine and therefore give the analysts access to the transformation function... finally, there are detection and prevention technologies (behaviour-based detectors, whitelists, etc) that can often stop malware without needing to know what the malware looks like and vendors are increasingly including such technology in their suites...
back to index
just as conventional polymorphism was constrained to housing the polymorphic engine within the virus its meant to operate on (because the code doing the copying has to have access to the transformation function), server-side polymorphism requires the polymorphic engine to be part of the system (generally a website) that serves (hands out) copies of the non-replicative malware it's used on instead of being in the malware itself...
this has proven to be very effective and very hard to counter from a conventional known-malware perspective... the reason is because with the polymorphic engine staying on the server instead of residing within the malware itself the transformation function can remain unknown to the malware analysts... although the analysts can try to perform black-box analysis of the transformation function, without knowing all the variables the function takes into account it's not possible to model the entire algorithm and predict all possible outputs... further, the transformation function can be arbitrarily complex, it could involve actually recompiling the malware with different parameters, or it might not even be an algorithm at all (someone might literally be manually changing the malware that the server is handing out)...
given this, it's not really possible in the general case for signature-based known-malware detection technology to reliably detect all instances of a piece of malware that employs server-side polymorphism but there are some facts that anti-malware vendors can use to their advantage... first, while signatures probably won't work, heuristics should be able to have some success against the various instances of such malware (assuming the polymorphism isn't too complex)... second, polymorphism has never been easy to develop and so the use (and sale) of kits may be helpful since the kits should contain the polymorphic engine and therefore give the analysts access to the transformation function... finally, there are detection and prevention technologies (behaviour-based detectors, whitelists, etc) that can often stop malware without needing to know what the malware looks like and vendors are increasingly including such technology in their suites...
back to index
what is metamorphism?
metamorphism can be thought of as a kind of polymorphism that doesn't use decryptors... in fact many of the techniques that polymorphic viruses used to vary their decryptors metamorphic viruses have used to vary their entire bodies...
metamorphism, like polymorphism, was a type of camouflage that was meant to fool anti-virus technology of the day... one of the successful solutions to polymorphism was to use a polymorphic virus' decryptor against it generically... by allowing it to run in an emulated environment so that the decryptor would reverse the obfuscation that had been performed on the main body of the virus, the de-obfuscated static virus body could then easily be matched against signatures...
rather than encrypt the virus' body and decrypt it when needed as a conventional polymorphic virus would, a metamorphic virus would vary it's entire body the way a polymorphic virus varied it's decryptor... since the transformation function used didn't need to be reversed in order for the code to run (otherwise decryptors in polymorphic viruses would have needed additional decryptors of their own), this meant that the virus' main body was generally never returned to an untransformed state during the normal operation of the virus and so would foil the previously mentioned tactic used against conventional polymorphism...
that said, the metamorphic engine (like the polymorphic engine) still must reside within the virus (in order for copies to have a different form the code doing the copying must have access to the transformation function) and that in itself was a weakness as it gave anti-virus vendors knowledge of the transformation function and therefore the ability to know (or at least derive) all forms a metamorphic virus could take...
back to index
metamorphism, like polymorphism, was a type of camouflage that was meant to fool anti-virus technology of the day... one of the successful solutions to polymorphism was to use a polymorphic virus' decryptor against it generically... by allowing it to run in an emulated environment so that the decryptor would reverse the obfuscation that had been performed on the main body of the virus, the de-obfuscated static virus body could then easily be matched against signatures...
rather than encrypt the virus' body and decrypt it when needed as a conventional polymorphic virus would, a metamorphic virus would vary it's entire body the way a polymorphic virus varied it's decryptor... since the transformation function used didn't need to be reversed in order for the code to run (otherwise decryptors in polymorphic viruses would have needed additional decryptors of their own), this meant that the virus' main body was generally never returned to an untransformed state during the normal operation of the virus and so would foil the previously mentioned tactic used against conventional polymorphism...
that said, the metamorphic engine (like the polymorphic engine) still must reside within the virus (in order for copies to have a different form the code doing the copying must have access to the transformation function) and that in itself was a weakness as it gave anti-virus vendors knowledge of the transformation function and therefore the ability to know (or at least derive) all forms a metamorphic virus could take...
back to index
what is polymorphism?
in the malware context, polymorphism refers to a property of self-replicating malware (viruses and worms, *although self-modifying non-replicative programs take on different forms by virtue of modifying themselves so the term polymorphism can technically apply to them also) whereby the offspring (the copies) potentially take on a different form than the parent (the original)...
typically polymorphism works by encrypting the main virus body (which was actually unchanging) using a variable key (in order to make the ciphertext actually be different from one instance to the next a different key is needed each time, otherwise it would simply be considered *encrypted) and using a decryptor (a stub that decrypts the main body of the virus in order for it to execute) that is also variable (otherwise the decryptor itself could be easily used to detect the virus)...
polymorphism is a type of camouflage that was originally developed back when anti-virus products were just using simple scan strings to compare against samples in the process of looking for viruses... a virus that changed it's contents could easily fool such a simple scanner because there would be no single sequence of bytes that would match all instances of the virus... as a result anti-virus companies developed technology that would use the virus' decryptor against it by allowing it to decrypt the main body of the virus so that that could then be used to identify the virus...
the term polymorph, in the malware context, arose out of a long telephone conversation between frisk (fridrik skulason) and alan solomon as a way to describe viruses that mutated or garbled themselves (according to dr. solly's retelling anyways) but over the years it has been narrowed to exclude cases where the decryptor didn't change (variably encrypted), or only changed into relatively few alternate forms (oligomorphs), or cases that didn't use a decryptor at all...
back to index
(*updates/improvements thanks to vesselin's comments)
typically polymorphism works by encrypting the main virus body (which was actually unchanging) using a variable key (in order to make the ciphertext actually be different from one instance to the next a different key is needed each time, otherwise it would simply be considered *encrypted) and using a decryptor (a stub that decrypts the main body of the virus in order for it to execute) that is also variable (otherwise the decryptor itself could be easily used to detect the virus)...
polymorphism is a type of camouflage that was originally developed back when anti-virus products were just using simple scan strings to compare against samples in the process of looking for viruses... a virus that changed it's contents could easily fool such a simple scanner because there would be no single sequence of bytes that would match all instances of the virus... as a result anti-virus companies developed technology that would use the virus' decryptor against it by allowing it to decrypt the main body of the virus so that that could then be used to identify the virus...
the term polymorph, in the malware context, arose out of a long telephone conversation between frisk (fridrik skulason) and alan solomon as a way to describe viruses that mutated or garbled themselves (according to dr. solly's retelling anyways) but over the years it has been narrowed to exclude cases where the decryptor didn't change (variably encrypted), or only changed into relatively few alternate forms (oligomorphs), or cases that didn't use a decryptor at all...
back to index
(*updates/improvements thanks to vesselin's comments)
the first rule of anti-virus fight club is don't let that kurt guy find out about it
awww, randy beat me to it, darn my self-imposed no-blog-posting-at-work rule... more than a few potential posts have wound up indefinitely stalled because of that rule but oh well... i'll post the thoughts i took down earlier anyways since there's a thing or two i can say that someone who's actually in the industry probably can't (or shouldn't)...
so i stumbled across this itblogwatch article about a group called untangle untangling av's mysteries and i was stunned... testing with 35 viruses? half of which submitted by the audience so we don't even know if they're really viruses? and clamav won? there are so many things wrong with this picture it's not even funny...
first, 35 viruses - 17 controlled (for lack of a better word), 17 submitted by the audience, and 1 test file - isn't enough to do anything except mislead people... this is the kind of test pc magazines used to do that were so laughably bad people were told to ignore them...
next, using samples submitted by the audience - can you see the audience sitting quietly for hours while the integrity of the samples they submitted was verified? no? me neither... ergo their integrity probably wasn't verified and so the results of that part of the test are next to useless...
further, who are the people submitting these samples? where do they come from and what company(ies) or organization(s) are they associated with? do they have ties of any kind with any of the products being tested? there's a potential for some significant sample selection bias here (magnified considerably by the ridiculously small sample size)...
and clamav? i generally don't bash actual products, but clamav? while some people may argue that anti-virus products are a commodity now, that doesn't mean that absolutely all of them are created equal - even if they are a commodity there are still going to be products on the fringes for which such general statements don't apply and unfortunately clamav is just such a product... the reason for this is that while av products may be a commodity, the expertise involved in creating virus scanning engines is not... it's highly specialized and few people have those skills - those that do are employed commercially and bound under various employment contracts in such a way as to not be able to contribute to the clamav open source project... and that's just the engine development, there's also considerable expertise involved in processing malware samples to add to a product's database and the people with those skills are also generally employed employed commercially... why do you think the number of entries in clamav's database has only ever been a fraction (generally about 1/3) of what commercial products have... there are all sorts projects for which open source works, but in order for it to work the knowledge required has to be fairly common and widely available in the community - something which just isn't true for av scanning engine/signature development...
at first blush it seemed to me that this av fight-club is a publicity stunt more than a reliable comparative review... then i dug a little deeper and found a few things:
the untangle documentation on their av fight club spins an interesting yarn about their dealings with other testing bodies and how they don't want to test clamav... though i can't speak for the more well regarded testing organizations, if you want to know why they don't bother testing clamav i wouldn't bother looking any further than the paltry 144,368 entries in their database (at the time of writing)... many products have passed 300,000 and some are as high as 500,000 (all figures include non-viral malware, obviously)... i'm sure they probably recheck clamav every once in a while to see if it's significantly improved or not (ie. can it reliably detect polymorphic viruses yet?) but so long as it's only detecting a fraction of what the other products detect it's not worth the time required to test it regularly...
and before anyone starts jumping up and down about how clam is only missing the 'old' malware that shouldn't be a problem anymore, let me first reiterate that old viruses never die (people are still looking for stoned.empire.monkey removal help 15 years after it was released), and let me also point out that considering the growth rate of malware, the 'old' stuff should be a minority fraction not a majority...
lastly, and this is not something i thought to mention originally but randy made a good point, including the eicar test file in this sort of test shows just how serious (or rather not serious) you should take these test results... it's sort of like giving the competitors marks for getting their names right... not only is detection of the test file almost guaranteed for all products, it's detection has no bearing on a product's ability to detect viruses because the test file isn't a virus or even virus-like in any way...
Update: it seems the composition of the test set may be different than i thought... mcafee are reporting that there are actually 6 eicar samples... they may be right, i don't know, none of the documentation says exactly how many of their samples came from eicar and since eicar really only has the one test file i assumed it only contributed that much to the test... the mcafee folks (in an effort to replicate the results) downloaded and examined the actual test set, something i refused to do (i wasn't going to denounce the distribution of viruses in one breath and then greedily gobble them up in the next, it's just not me), so they're probably right about how many of the samples are the eicar file... i can't imagine how they got 6 eicar samples, though, since eicar only provides the one test file in 3 different forms (4 if you think changing the file extension qualifies)... at any rate, sextuple counting the eicar test file is just weird...
so i stumbled across this itblogwatch article about a group called untangle untangling av's mysteries and i was stunned... testing with 35 viruses? half of which submitted by the audience so we don't even know if they're really viruses? and clamav won? there are so many things wrong with this picture it's not even funny...
first, 35 viruses - 17 controlled (for lack of a better word), 17 submitted by the audience, and 1 test file - isn't enough to do anything except mislead people... this is the kind of test pc magazines used to do that were so laughably bad people were told to ignore them...
next, using samples submitted by the audience - can you see the audience sitting quietly for hours while the integrity of the samples they submitted was verified? no? me neither... ergo their integrity probably wasn't verified and so the results of that part of the test are next to useless...
further, who are the people submitting these samples? where do they come from and what company(ies) or organization(s) are they associated with? do they have ties of any kind with any of the products being tested? there's a potential for some significant sample selection bias here (magnified considerably by the ridiculously small sample size)...
and clamav? i generally don't bash actual products, but clamav? while some people may argue that anti-virus products are a commodity now, that doesn't mean that absolutely all of them are created equal - even if they are a commodity there are still going to be products on the fringes for which such general statements don't apply and unfortunately clamav is just such a product... the reason for this is that while av products may be a commodity, the expertise involved in creating virus scanning engines is not... it's highly specialized and few people have those skills - those that do are employed commercially and bound under various employment contracts in such a way as to not be able to contribute to the clamav open source project... and that's just the engine development, there's also considerable expertise involved in processing malware samples to add to a product's database and the people with those skills are also generally employed employed commercially... why do you think the number of entries in clamav's database has only ever been a fraction (generally about 1/3) of what commercial products have... there are all sorts projects for which open source works, but in order for it to work the knowledge required has to be fairly common and widely available in the community - something which just isn't true for av scanning engine/signature development...
at first blush it seemed to me that this av fight-club is a publicity stunt more than a reliable comparative review... then i dug a little deeper and found a few things:
- the organization (untangle) conducting the fight-club uses clamav in their own product and so cannot be trusted not to cook the results in that engine's favour in some way or another (ex. sample selection, test design, etc.)...
- the organization that conducted the test is distributing live viruses to the public, which is totally unacceptable - the center for disease control doesn't hand out free samples and neither should people dealing with computer viruses...
the untangle documentation on their av fight club spins an interesting yarn about their dealings with other testing bodies and how they don't want to test clamav... though i can't speak for the more well regarded testing organizations, if you want to know why they don't bother testing clamav i wouldn't bother looking any further than the paltry 144,368 entries in their database (at the time of writing)... many products have passed 300,000 and some are as high as 500,000 (all figures include non-viral malware, obviously)... i'm sure they probably recheck clamav every once in a while to see if it's significantly improved or not (ie. can it reliably detect polymorphic viruses yet?) but so long as it's only detecting a fraction of what the other products detect it's not worth the time required to test it regularly...
and before anyone starts jumping up and down about how clam is only missing the 'old' malware that shouldn't be a problem anymore, let me first reiterate that old viruses never die (people are still looking for stoned.empire.monkey removal help 15 years after it was released), and let me also point out that considering the growth rate of malware, the 'old' stuff should be a minority fraction not a majority...
lastly, and this is not something i thought to mention originally but randy made a good point, including the eicar test file in this sort of test shows just how serious (or rather not serious) you should take these test results... it's sort of like giving the competitors marks for getting their names right... not only is detection of the test file almost guaranteed for all products, it's detection has no bearing on a product's ability to detect viruses because the test file isn't a virus or even virus-like in any way...
Update: it seems the composition of the test set may be different than i thought... mcafee are reporting that there are actually 6 eicar samples... they may be right, i don't know, none of the documentation says exactly how many of their samples came from eicar and since eicar really only has the one test file i assumed it only contributed that much to the test... the mcafee folks (in an effort to replicate the results) downloaded and examined the actual test set, something i refused to do (i wasn't going to denounce the distribution of viruses in one breath and then greedily gobble them up in the next, it's just not me), so they're probably right about how many of the samples are the eicar file... i can't imagine how they got 6 eicar samples, though, since eicar only provides the one test file in 3 different forms (4 if you think changing the file extension qualifies)... at any rate, sextuple counting the eicar test file is just weird...
Thursday, August 02, 2007
the blue pill - once more, with feeling
i kinda hoped to never again darken my blog with those two words again... i even resisted the temptation to point to the response to the matasano challenge and say 'nyah, nyah, i told you so'...
and frankly, i'm not even interested in debunking the hogwash about it being 100% undetectable anymore - i know that perfect protection from detectors is impossible, joanna knows it's impossible, and i know that joanna knows that it's impossible...
if it were any of that stuff i've already posted about before i wouldn't be posting again because i've already said my peace about that... no, despite all the faults, all the criticisms i've made, the one good thing i was able to say was that at least she didn't release it - at least she was being responsible...
now even that is gone... maybe i should write viruses, slap a research sticker on them, release them and call it good... does that work? no? i didn't think so...
was there a compelling reason to make the stealthkit available to the public? was someone feeling the heat over some ridiculous claims and rather than eat crow decided to let those detractors test it for themselves with thecop-out caveat that it's not finished?... seems a plausible explanation - at any rate, congratulations joanna on becoming part of the problem, i'm sure that black hat you've made yourself will go over well at that conference by the same name...
and frankly, i'm not even interested in debunking the hogwash about it being 100% undetectable anymore - i know that perfect protection from detectors is impossible, joanna knows it's impossible, and i know that joanna knows that it's impossible...
if it were any of that stuff i've already posted about before i wouldn't be posting again because i've already said my peace about that... no, despite all the faults, all the criticisms i've made, the one good thing i was able to say was that at least she didn't release it - at least she was being responsible...
now even that is gone... maybe i should write viruses, slap a research sticker on them, release them and call it good... does that work? no? i didn't think so...
was there a compelling reason to make the stealthkit available to the public? was someone feeling the heat over some ridiculous claims and rather than eat crow decided to let those detractors test it for themselves with the
Saturday, July 21, 2007
silencing the sellout
well, it's been a couple days since i tore anyone a new one so here goes... some of you may be familiar with the mess revolving around the infosecsellout blog (as discussed at these sites 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, not to mention slashdot) but if not, here's my perspective...
to start out, infosecsellout announced the discovery of a remotely exploitable mac vulnerability but he/she/they weren't finished working on it so he/she/they weren't ready to give apple the details yet... nothing new with finding mac vulnerabilities (that is why apple has been releasing security patches after all) but i suppose it was a little pointless to announce the existence of the vulnerability to the community before you're ready to do anything about it for the community...
then infosecsellout wrote a worm that exploited the vulnerability... obviously i'm not going to condone writing malware, but to his/her/their credit at least he/she/they weren't going to release it to the public, only to his/her/their employer - and he/she/they may have had good reason to trust that that employer wouldn't do anything stupid or malicious with the worm so it might have been responsible handling of malware (at least after the fact, though there are better ways to go about proving things)...
then the criticism started rolling in... obviously writing malware for the mac at this stage isn't proving the mac is vulnerable to malware since that was objectively proven some time ago, but the criticism went beyond that... some apparently felt that details should be given to apple when they (rather than the researcher) felt the researcher was ready... others felt (perhaps justifiably) that without proof of the vulnerability and without a reputation to fall back on (an inherent limitation of anonymity) that there was no reason to believe the vulnerability claim was legitimate... ah to be a mac fan...
all that seems fairly civilized so far, but some folks decided they'd rather have infosecsellout shut up and thus he/she/they started receiving death threats... were some of them mac fans? maybe... were some of them security professionals? probably since they implied they'd be at security-related events when they put a bullet in the sellout and buried him/her (no them, since the people making threats didn't seem to consider the fact that they'd need to deal with more than one person)... there are some pretty twisted people in the world and threatening death and/or mutilation over an exploit is pretty despicable, i have to agree with dave lewis on that one... although in usenet i often used to see people wish to see virus writers strung up by their testicles or various other body parts so as sick as it may be perhaps it's more common than anyone wants to admit...
another attack seemingly designed to silence the infosecsellout was an attack against his/her/their identity(/ies)... security professionals, whining about the mean and nasty things infosecsellout has said (oh, boo hoo - toughen up kids, this is the internet not a school playground), tried to out the infosecsellout... first of all, this is a dangerous thing to do to someone who is receiving death threats... were the threats real? it's impossible to know for sure but when it comes to people's lives i think it's probably better to err on the side of caution... second, although it may be true that there is no real anonymity on the internet (especially where security pros are concerned) the same can be said for privacy... anonymity, like privacy, is a luxury we afford each other and we do so because we value these things and want others to afford those luxuries to us... just as privacy is a prerequisite for personal liberty, anonymity is a prerequisite for freedom of speech - and i'm not talking about happy/friendly speech that doesn't need protecting in the first place, it's unpopular speech that anonymity is designed to protect... you should expect to not like unpopular speech, but you should also understand why a free society needs it... i regard those who disrespect anonymity with the same sort of disdain as those who disrespect privacy (like peeping toms or hammer hawks)...
the blog hijacking, had it been a real one like these two from recent memory instead of just fat fingers (so there's an insider threat even in blogging!) and a cooperative blog creator, would have come the closest to shutting him/her/them up... but even when the blog seemed to be gone, infosecsellout was still getting his/her/their voice(s) heard in blog comments so it would seem that the infosecsellout is here for the duration and folks should just get used to it...
if you think the infosecsellout is a troll then act accordingly and stop paying attention to him/her/them... if you don't like the things infosecsellout has to say, just about the worst thing you could do would be to lend credence to those things by trying to silence him/her/them...
(and if you're wondering why i didn't link directly to the infosecsellout blog, or why the blog doesn't appear in my blogroll at the time of writing even though it used to, look no further than the supposedly corrected hijacking [and, i suppose the malware writing]... it's back on my probationary list for now...)
to start out, infosecsellout announced the discovery of a remotely exploitable mac vulnerability but he/she/they weren't finished working on it so he/she/they weren't ready to give apple the details yet... nothing new with finding mac vulnerabilities (that is why apple has been releasing security patches after all) but i suppose it was a little pointless to announce the existence of the vulnerability to the community before you're ready to do anything about it for the community...
then infosecsellout wrote a worm that exploited the vulnerability... obviously i'm not going to condone writing malware, but to his/her/their credit at least he/she/they weren't going to release it to the public, only to his/her/their employer - and he/she/they may have had good reason to trust that that employer wouldn't do anything stupid or malicious with the worm so it might have been responsible handling of malware (at least after the fact, though there are better ways to go about proving things)...
then the criticism started rolling in... obviously writing malware for the mac at this stage isn't proving the mac is vulnerable to malware since that was objectively proven some time ago, but the criticism went beyond that... some apparently felt that details should be given to apple when they (rather than the researcher) felt the researcher was ready... others felt (perhaps justifiably) that without proof of the vulnerability and without a reputation to fall back on (an inherent limitation of anonymity) that there was no reason to believe the vulnerability claim was legitimate... ah to be a mac fan...
all that seems fairly civilized so far, but some folks decided they'd rather have infosecsellout shut up and thus he/she/they started receiving death threats... were some of them mac fans? maybe... were some of them security professionals? probably since they implied they'd be at security-related events when they put a bullet in the sellout and buried him/her (no them, since the people making threats didn't seem to consider the fact that they'd need to deal with more than one person)... there are some pretty twisted people in the world and threatening death and/or mutilation over an exploit is pretty despicable, i have to agree with dave lewis on that one... although in usenet i often used to see people wish to see virus writers strung up by their testicles or various other body parts so as sick as it may be perhaps it's more common than anyone wants to admit...
another attack seemingly designed to silence the infosecsellout was an attack against his/her/their identity(/ies)... security professionals, whining about the mean and nasty things infosecsellout has said (oh, boo hoo - toughen up kids, this is the internet not a school playground), tried to out the infosecsellout... first of all, this is a dangerous thing to do to someone who is receiving death threats... were the threats real? it's impossible to know for sure but when it comes to people's lives i think it's probably better to err on the side of caution... second, although it may be true that there is no real anonymity on the internet (especially where security pros are concerned) the same can be said for privacy... anonymity, like privacy, is a luxury we afford each other and we do so because we value these things and want others to afford those luxuries to us... just as privacy is a prerequisite for personal liberty, anonymity is a prerequisite for freedom of speech - and i'm not talking about happy/friendly speech that doesn't need protecting in the first place, it's unpopular speech that anonymity is designed to protect... you should expect to not like unpopular speech, but you should also understand why a free society needs it... i regard those who disrespect anonymity with the same sort of disdain as those who disrespect privacy (like peeping toms or hammer hawks)...
the blog hijacking, had it been a real one like these two from recent memory instead of just fat fingers (so there's an insider threat even in blogging!) and a cooperative blog creator, would have come the closest to shutting him/her/them up... but even when the blog seemed to be gone, infosecsellout was still getting his/her/their voice(s) heard in blog comments so it would seem that the infosecsellout is here for the duration and folks should just get used to it...
if you think the infosecsellout is a troll then act accordingly and stop paying attention to him/her/them... if you don't like the things infosecsellout has to say, just about the worst thing you could do would be to lend credence to those things by trying to silence him/her/them...
(and if you're wondering why i didn't link directly to the infosecsellout blog, or why the blog doesn't appear in my blogroll at the time of writing even though it used to, look no further than the supposedly corrected hijacking [and, i suppose the malware writing]... it's back on my probationary list for now...)
Tuesday, July 17, 2007
microsoft's anti-malware ethical conflict
regular readers can probably recall me saying that anti-virus companies don't hire virus writers on occasion... i've called the notion that anti-virus companies are paying for the creation of viruses an urban myth because it would just be too hard to keep that sort of thing secret from their competitors and if their competitors found out about it they'd use it to hurt the company and free up some of it's market share for themselves... each company acts as a watchdog for the others, waiting to blow the whistle on ethical misconduct and in this way they actually help to keep each other honest...
now you'd think this same principle would work for other forms of malware besides viruses, but as i've shown in the past (here and here) that's not always the case... still, it should probably come as a surprise that microsoft, after sinking untold amounts of resources into entering the anti-malware market, has filed for patents on adware/spyware technology... no, not anti-adware/anti-spyware technology, literally technology to serve you ads (adware) based on the contents of your hard drive (spyware)...
so not only does microsoft have conflict where their anti-malware software may prove a disincentive to fixing vulnerabilities in their other software (not to mention that they're charging you money to protect against threats exploiting flaws in their other software) but now they have an ethical conflict where they're considering producing malware and anti-malware at the same time... apparently some of the PHBs at microsoft haven't gotten the memo yet about the new ethical constraints of the company now that it produces anti-malware software... let me put it as bluntly as possible: if you're going to be an anti-malware company you have to be anti-malware... that means no malware creation or malware-based revenue for you...
i, for one, would neither feel comfortable using nor endorsing the use of anti-malware software produced by an entity that ever seriously considered producing malware, never mind one that did so while producing the anti-malware in question at the same time...
now you'd think this same principle would work for other forms of malware besides viruses, but as i've shown in the past (here and here) that's not always the case... still, it should probably come as a surprise that microsoft, after sinking untold amounts of resources into entering the anti-malware market, has filed for patents on adware/spyware technology... no, not anti-adware/anti-spyware technology, literally technology to serve you ads (adware) based on the contents of your hard drive (spyware)...
so not only does microsoft have conflict where their anti-malware software may prove a disincentive to fixing vulnerabilities in their other software (not to mention that they're charging you money to protect against threats exploiting flaws in their other software) but now they have an ethical conflict where they're considering producing malware and anti-malware at the same time... apparently some of the PHBs at microsoft haven't gotten the memo yet about the new ethical constraints of the company now that it produces anti-malware software... let me put it as bluntly as possible: if you're going to be an anti-malware company you have to be anti-malware... that means no malware creation or malware-based revenue for you...
i, for one, would neither feel comfortable using nor endorsing the use of anti-malware software produced by an entity that ever seriously considered producing malware, never mind one that did so while producing the anti-malware in question at the same time...
Monday, July 16, 2007
sony vs. the drm manufacturer
as has been reported in a number of places, sony has filed a suit against amergence (formerly sunncomm) because the drm they provided to sony was 'defective'...
contrary to what a number of folks have written, this has nothing to do with rootkits (and not just because 'rootkit' is the most misused term in anti-malware since 'virus')... the reason this has nothing to do with rootkits and the whole sony 'rootkit' debacle is that that debacle involved drm produced by a company called first4internet, not sunncomm...
sony was employing drm technology from 2 separate companies at the same time (xcp from first4internet and mediamax from sunncomm) and sunncomm was able to fly mostly under the radar because most people were so focused on the stealthkit functionality of xcp... of course the added attention to sony cd's probably did raise awareness of the spyware-like qualities of mediamax, but considering that even now most people jump to the conclusion that sony+drm='rootkit' it's clear that sunncomm dodged a big PR bullet when that fiasco was going on...
but all good things come to an end and now they're being sued for reasons that most people are associating with the 'rootkit' debacle... one probably wonders, then, why sony isn't suing firts4internet instead (since first4interent's xcp cost sony a heck of a lot more than sunncomm's mediamax), and i wonder how they're being sued at all since software liability is supposed to be something we need not something we have (if schneier is to be believed)... my best guess is that with existing precedents for spyware prosecution, sony may believe they have a better chance of a judgment in their favour with a sunncomm suit than with a first4internet suit... however, if the claims that sony had final say on the functional specification of the software is true (and given that control is a strong motivator in the decision to deploy drm, it wouldn't surprise me if those claims were true), then sony shares an equal portion of the blame for anything the software did to sony's customers...
but the true lesson in this is for drm providers everywhere: if you're unethical enough to try and provide drm technology, you may one day find your customers (the content industry) trying to bite the hand that feeds them (you)... and when that happens, having customers with deep pockets won't seem like such a blessing anymore...
contrary to what a number of folks have written, this has nothing to do with rootkits (and not just because 'rootkit' is the most misused term in anti-malware since 'virus')... the reason this has nothing to do with rootkits and the whole sony 'rootkit' debacle is that that debacle involved drm produced by a company called first4internet, not sunncomm...
sony was employing drm technology from 2 separate companies at the same time (xcp from first4internet and mediamax from sunncomm) and sunncomm was able to fly mostly under the radar because most people were so focused on the stealthkit functionality of xcp... of course the added attention to sony cd's probably did raise awareness of the spyware-like qualities of mediamax, but considering that even now most people jump to the conclusion that sony+drm='rootkit' it's clear that sunncomm dodged a big PR bullet when that fiasco was going on...
but all good things come to an end and now they're being sued for reasons that most people are associating with the 'rootkit' debacle... one probably wonders, then, why sony isn't suing firts4internet instead (since first4interent's xcp cost sony a heck of a lot more than sunncomm's mediamax), and i wonder how they're being sued at all since software liability is supposed to be something we need not something we have (if schneier is to be believed)... my best guess is that with existing precedents for spyware prosecution, sony may believe they have a better chance of a judgment in their favour with a sunncomm suit than with a first4internet suit... however, if the claims that sony had final say on the functional specification of the software is true (and given that control is a strong motivator in the decision to deploy drm, it wouldn't surprise me if those claims were true), then sony shares an equal portion of the blame for anything the software did to sony's customers...
but the true lesson in this is for drm providers everywhere: if you're unethical enough to try and provide drm technology, you may one day find your customers (the content industry) trying to bite the hand that feeds them (you)... and when that happens, having customers with deep pockets won't seem like such a blessing anymore...
Sunday, July 15, 2007
how NOT to fight spam with gmail
there's a rather misguided piece of gmail-related anti-spam advice that crops up from time to time and has been seen most recently here, here, and here... i try to debunk this whenever i see it but gosh darn it the blog comments just don't seem to be getting through to people so . . .
the basic idea is to transform your gmail address (using the well known transformations of adding extraneous dots or the '+keyword' trick) when you give it out to sites so that when (not if) the address gets misused by spammers you can easily make a filter to delete mail sent to that address...
here's an example: the.president@gmail.com
here's another example: thepresident+nopoliticalmessagehere@gmail.com
now, these tricks are well known, they're easy to apply, but most importantly they're easy to reverse because all the information needed to determine what the true gmail address is must remain present for the tricks to work... if you know that google ignores any dots before the @ sign can you guess what address email to the.president@gmail.com gets delivered to? yeah, thepresident@gmail.com... futher, if you know that everything between the + and @ get ignored (+ inclusive) can you guess where email to thepresident+nopoliticalmessagehere@gmail.com gets delivered to? once again, thepresident@gmail.com...
doesn't seem like rocket science, in fact, it's so easy you can write a program to do it for you - and not to put too fine a point on it but it's almost a certainty that someone already has and put the functionality into an email address management program used by email harvesters and spammers...
that means this trick has next to no value in actually combating spam... i've written before about handing out special email addresses to web sites to help stop spam but the key aspect to that, the thing that makes it actually work, is that your true email address remains secret... not only does the gmail id aliasing trick not keep your true gmail address secret, it gives the spammers the opportunity to create arbitrarily many other aliases so that you can never filter by alias - if you filter out mail to the.president and thepresident, mail to t.h.e.p.r.e.s.i.d.e.n.t will still get through as will mail to thepresident+wants.v1agr4...
these tricks can be useful for organizing incoming mail, but if you want to combat spam by handing out special email addresses you have to use addresses that keep your true address secret...
the basic idea is to transform your gmail address (using the well known transformations of adding extraneous dots or the '+keyword' trick) when you give it out to sites so that when (not if) the address gets misused by spammers you can easily make a filter to delete mail sent to that address...
here's an example: the.president@gmail.com
here's another example: thepresident+nopoliticalmessagehere@gmail.com
now, these tricks are well known, they're easy to apply, but most importantly they're easy to reverse because all the information needed to determine what the true gmail address is must remain present for the tricks to work... if you know that google ignores any dots before the @ sign can you guess what address email to the.president@gmail.com gets delivered to? yeah, thepresident@gmail.com... futher, if you know that everything between the + and @ get ignored (+ inclusive) can you guess where email to thepresident+nopoliticalmessagehere@gmail.com gets delivered to? once again, thepresident@gmail.com...
doesn't seem like rocket science, in fact, it's so easy you can write a program to do it for you - and not to put too fine a point on it but it's almost a certainty that someone already has and put the functionality into an email address management program used by email harvesters and spammers...
that means this trick has next to no value in actually combating spam... i've written before about handing out special email addresses to web sites to help stop spam but the key aspect to that, the thing that makes it actually work, is that your true email address remains secret... not only does the gmail id aliasing trick not keep your true gmail address secret, it gives the spammers the opportunity to create arbitrarily many other aliases so that you can never filter by alias - if you filter out mail to the.president and thepresident, mail to t.h.e.p.r.e.s.i.d.e.n.t will still get through as will mail to thepresident+wants.v1agr4...
these tricks can be useful for organizing incoming mail, but if you want to combat spam by handing out special email addresses you have to use addresses that keep your true address secret...
what happens when the malware stops?
not too long ago there was a post about wabisabilabi on the authentium blog that was interesting on a couple of different levels...
rjs' primary angle was ethics, and i can't really fault anything he wrote - it sounds dead-on to me, not to mention being very much in line with sentiments i've seen many other av personalities make over the years...
but there was one question that the wabisabilabi blogger asked and rjs answered that i think bears closer examination... the question is, essentially, what happens if/when everyone stops writing malware... both the asking of the question and the answer given seem to operate under the assumption that malware will cease to be a problem if/when people stop writing it...
however, as i've observed previously, old viruses never die so that assumption doesn't seem to hold... in fact, as i've suggested on more than one occasion, self-replicating malware will continue to pose a threat long after anyone associated with it's release loses interest and moves on... so long as it poses a threat there will be a need for anti-malware software so the shareholders that wabisabilabi's blogger feigned concern for shouldn't need to worry about their investment becoming completely worthless...
of course one could make the argument that without new malware the nature of what anti-malware companies do would be irrevocably changed - and while that's true it's not as big a change as one might think (at least not right away)... you see, the products detect hundreds of thousands of instances of malware but do they do so perfectly? do they do so optimally? what about removal, is that perfect or optimal in all cases? the answer is no on all counts so there is still plenty of room for malware analysts and engine designers to make improvements... even after all that gets taken care of, it's not like the lack of compelling reasons to upgrade have hurt the word processor market or stopped microsoft from regularly releasing new versions of word...
so it really doesn't seem like the end of malware writing would be all that damaging to the anti-malware business, but what i'd like to do now is take a step back and look at look at what the end of malware would mean... as i've mentioned before malware is (or at least starts out as) a proxy for the intent of a human attacker so why would such attackers stop employing this particular technique for attacking digital assets and resources? malware is a way for an attacker to benefit from automation and make their attacks easier to perform - the most likely reason (though still very unlikely) for them to give that up would be that they were giving up attacking digital assets/resources entirely... in which case, by rjs' reasoning it shouldn't just be the anti-malware folks throwing parties and getting blitzed, it should be the entire computer security industry because the giant pain in the ass that protecting those resources represents will be over...
but let's go further... attacking digital assets/resources is just one of many avenues that people use to attack each other - why give up one and not the others? either computers stop being a useful avenue of attack (which likely can only happen if computers simply stop being useful - seems like a rather apocalyptic change) or people just stop attacking each other... when man stops attacking his fellow man it will be just as much the end of the world as we know it as if it were a conventional apocalypse, only nicer... either way, the end of malware writing would signal the end many other things...
that's not to say that the end of malware writing would cause an apocalypse or that writing malware keeps the world from falling off it's axis - malware is not the cause of things, it is a symptom of the human condition and the only way for it to go away is if the human condition itself undergoes a fundamental and profound change... as such, there's really no problem with anti-malware vendors discouraging malware writing... nobody's under any illusions about whether or not it's going to stop malware from being written, but it is the ethical high road and it is the right thing for them to do...
and if anyone has an even longer view i'd love to hear it...
rjs' primary angle was ethics, and i can't really fault anything he wrote - it sounds dead-on to me, not to mention being very much in line with sentiments i've seen many other av personalities make over the years...
but there was one question that the wabisabilabi blogger asked and rjs answered that i think bears closer examination... the question is, essentially, what happens if/when everyone stops writing malware... both the asking of the question and the answer given seem to operate under the assumption that malware will cease to be a problem if/when people stop writing it...
however, as i've observed previously, old viruses never die so that assumption doesn't seem to hold... in fact, as i've suggested on more than one occasion, self-replicating malware will continue to pose a threat long after anyone associated with it's release loses interest and moves on... so long as it poses a threat there will be a need for anti-malware software so the shareholders that wabisabilabi's blogger feigned concern for shouldn't need to worry about their investment becoming completely worthless...
of course one could make the argument that without new malware the nature of what anti-malware companies do would be irrevocably changed - and while that's true it's not as big a change as one might think (at least not right away)... you see, the products detect hundreds of thousands of instances of malware but do they do so perfectly? do they do so optimally? what about removal, is that perfect or optimal in all cases? the answer is no on all counts so there is still plenty of room for malware analysts and engine designers to make improvements... even after all that gets taken care of, it's not like the lack of compelling reasons to upgrade have hurt the word processor market or stopped microsoft from regularly releasing new versions of word...
so it really doesn't seem like the end of malware writing would be all that damaging to the anti-malware business, but what i'd like to do now is take a step back and look at look at what the end of malware would mean... as i've mentioned before malware is (or at least starts out as) a proxy for the intent of a human attacker so why would such attackers stop employing this particular technique for attacking digital assets and resources? malware is a way for an attacker to benefit from automation and make their attacks easier to perform - the most likely reason (though still very unlikely) for them to give that up would be that they were giving up attacking digital assets/resources entirely... in which case, by rjs' reasoning it shouldn't just be the anti-malware folks throwing parties and getting blitzed, it should be the entire computer security industry because the giant pain in the ass that protecting those resources represents will be over...
but let's go further... attacking digital assets/resources is just one of many avenues that people use to attack each other - why give up one and not the others? either computers stop being a useful avenue of attack (which likely can only happen if computers simply stop being useful - seems like a rather apocalyptic change) or people just stop attacking each other... when man stops attacking his fellow man it will be just as much the end of the world as we know it as if it were a conventional apocalypse, only nicer... either way, the end of malware writing would signal the end many other things...
that's not to say that the end of malware writing would cause an apocalypse or that writing malware keeps the world from falling off it's axis - malware is not the cause of things, it is a symptom of the human condition and the only way for it to go away is if the human condition itself undergoes a fundamental and profound change... as such, there's really no problem with anti-malware vendors discouraging malware writing... nobody's under any illusions about whether or not it's going to stop malware from being written, but it is the ethical high road and it is the right thing for them to do...
and if anyone has an even longer view i'd love to hear it...
Tuesday, July 03, 2007
what's happening to security blogs on blogger.com?
over the weekend i received an email (thanks again, luke) alerting me to the fact that the blog for superantispyware (a well known and respected anti-spyware application) had been compromised and was serving up malware... on checking my stats i saw that there were a few clicks on that link in my blogroll over the course of the past month so i was concerned and tried to get details from nick skrepetos, but while waiting for a response i find out via the sunbelt blog that a virtually identical fate has befallen another security related blogger.com blog...
is it just those two? are there more? is it just security blogs being compromised or is it just blogger.com blogs in general that are falling victim to the malware profiteers? it seems an unlikely coincidence that 2 security blogs on blogger.com would be found compromised and serving malware around the same time due to unrelated causes... as a blogger.com user myself and a security blogger, i'd really be interested in further details on how the compromise happened - as i'm sure quite a number of other security bloggers who use blogger.com are...
at any rate, if you've visited either of the 2 blogs in question recently, you might want to give your system a thorough inspection - just to be safe...
is it just those two? are there more? is it just security blogs being compromised or is it just blogger.com blogs in general that are falling victim to the malware profiteers? it seems an unlikely coincidence that 2 security blogs on blogger.com would be found compromised and serving malware around the same time due to unrelated causes... as a blogger.com user myself and a security blogger, i'd really be interested in further details on how the compromise happened - as i'm sure quite a number of other security bloggers who use blogger.com are...
at any rate, if you've visited either of the 2 blogs in question recently, you might want to give your system a thorough inspection - just to be safe...
Sunday, July 01, 2007
the three preventative paradigms
something i've had circling around in my head for a while now is a fundamental division between malware prevention techniques... i'm moderately certain i've missed something (because three just comes up way too often in security) but it seems to me that everything falls into one (or more) of three broad categories: blacklisting, whitelisting, and sandboxing...
i know, right now you're probably saying "kurt! you missed a whole bunch of stuff - what about heuristics? what about behavioural techniques?"... well, lets look at that - what does behaviour-based malware detection do anyways? it monitors behaviours, sure, but how does it decide something is bad? what's going on is that it's actually comparing the behaviours (or combinations thereof) to a list of known bad behaviours (or behaviour combinations) which means it's a type of behavioural blacklist... likewise, heuristics compares properties (like the presence of certain familiar routines) of the program being scanned to a list of properties known to be used in bad programs and so also represents a type of blacklist... the blacklist technique is not the exclusive domain of signature scanning... anything that tries to identify something as bad (basically anything that tries to algorithmically answer the question "is this bad?") must do so by comparing it or some aspect of it to a list of known bad things of a similar type - and that makes it a blacklist...
"but kurt," you say, "that's not the only kind of behavioural technique out there. what about ones where you define what behaviour different programs are allowed to perform such as provided by various HIPS products?"... well, you'd be right, that behavioural technique is not a blacklist... besides being a process-centric access control system, it is more generally a behavioural whitelist... just as the blacklist technique is not exclusive to signature-based virus scanning, the whitelist technique is not so narrowly defined as to only specify application launch whitelists and/or the preferred paradigm for deploying firewalls... if it tries to block everything that isn't good/allowed/authorized (rather than everything that is bad/not allowed/unauthorized) then it must first be able to answer the question "is this good/allowed/authorized?" and to do that it must have a list of known good/allowed/authorized things - and that is a whitelist...
so if it answers the "is it bad?" question it's a blacklist and if it answers the "is it good?" question it's a whitelist - what's left? you might think it's some combination of the two but in fact it's not answering any question at all... the truth is our ability to answer either of those questions is limited so we need to take care of the case where we can't answer either of them and that's what a sandbox does... rather than blocking things outright based on knowledge of what's good or what's bad, sandboxing prevents malware intrusion to the host system by misdirection... the software which may or may not be malware is given a sandboxed environment to work in rather than the host environment and barring any ability to escape sandboxes, what happens in the sandbox (good or bad) stays in the sandbox... it doesn't necessarily prevent extrusion (leaking) of sensitive data you enter into applications running in the sandbox, mind you, and in that sense is a lesser form of prevention - but preventing malware from affecting the host system without any knowledge of or ability to decide on what's good or bad is no small feat...
if we could just assume everything that a blacklist doesn't alert on was good then life would be simple, but unfortunately that's not the case... likewise, assuming everything that isn't on a whitelist must be bad isn't very useful either (at least not unless you're dealing with very restrictive environments and even then there are complications)... once again, these three approaches are complementary and are best used together...
i know, right now you're probably saying "kurt! you missed a whole bunch of stuff - what about heuristics? what about behavioural techniques?"... well, lets look at that - what does behaviour-based malware detection do anyways? it monitors behaviours, sure, but how does it decide something is bad? what's going on is that it's actually comparing the behaviours (or combinations thereof) to a list of known bad behaviours (or behaviour combinations) which means it's a type of behavioural blacklist... likewise, heuristics compares properties (like the presence of certain familiar routines) of the program being scanned to a list of properties known to be used in bad programs and so also represents a type of blacklist... the blacklist technique is not the exclusive domain of signature scanning... anything that tries to identify something as bad (basically anything that tries to algorithmically answer the question "is this bad?") must do so by comparing it or some aspect of it to a list of known bad things of a similar type - and that makes it a blacklist...
"but kurt," you say, "that's not the only kind of behavioural technique out there. what about ones where you define what behaviour different programs are allowed to perform such as provided by various HIPS products?"... well, you'd be right, that behavioural technique is not a blacklist... besides being a process-centric access control system, it is more generally a behavioural whitelist... just as the blacklist technique is not exclusive to signature-based virus scanning, the whitelist technique is not so narrowly defined as to only specify application launch whitelists and/or the preferred paradigm for deploying firewalls... if it tries to block everything that isn't good/allowed/authorized (rather than everything that is bad/not allowed/unauthorized) then it must first be able to answer the question "is this good/allowed/authorized?" and to do that it must have a list of known good/allowed/authorized things - and that is a whitelist...
so if it answers the "is it bad?" question it's a blacklist and if it answers the "is it good?" question it's a whitelist - what's left? you might think it's some combination of the two but in fact it's not answering any question at all... the truth is our ability to answer either of those questions is limited so we need to take care of the case where we can't answer either of them and that's what a sandbox does... rather than blocking things outright based on knowledge of what's good or what's bad, sandboxing prevents malware intrusion to the host system by misdirection... the software which may or may not be malware is given a sandboxed environment to work in rather than the host environment and barring any ability to escape sandboxes, what happens in the sandbox (good or bad) stays in the sandbox... it doesn't necessarily prevent extrusion (leaking) of sensitive data you enter into applications running in the sandbox, mind you, and in that sense is a lesser form of prevention - but preventing malware from affecting the host system without any knowledge of or ability to decide on what's good or bad is no small feat...
if we could just assume everything that a blacklist doesn't alert on was good then life would be simple, but unfortunately that's not the case... likewise, assuming everything that isn't on a whitelist must be bad isn't very useful either (at least not unless you're dealing with very restrictive environments and even then there are complications)... once again, these three approaches are complementary and are best used together...
Wednesday, June 27, 2007
more on whitelisting
or perhaps moron whitelisting... yes dave, i'm taking the bait with the emperor's robin bloor's new clothes article about the decline of anti-virus and the rise of whitelisting... and it's pretty good bait too, since i wrote the rise of whitelisting (anything look familiar?) over a year ago in response to something else robin wrote when his misguided anti-virus-is-dead campaign was still new (a day old judging by the posting dates)...
i haven't really seen much new material that i didn't cover myself in that first response - exotic execution, accuracy of local whitelist management, and scalability of global whitelist management are all outstanding problems with whitelisting... finding out that the whitelist vendors themselves admit to the unmanageable scope of their own efforts is one of the few new things that have come up since then...
robin doesn't address any of this, of course, and like the emperor's new clothes there really isn't anything there in his new article... 2 whitelist companies merged and became bigger than either was before - big woop...
the only interesting things were the comments on the register's mirror of the article... vesselin bontchev hit the nail on the head several times (and i'd expect nothing less, though i wouldn't have expected vess to be first to post on the register - ugh), but what interested me most was the suggestion that robin bloor's 'research' is funded by the whitelist industry...
clearly this would be some segment of the whitelist industry that is misguided enough to think that anti-virus companies are actually their competitors... it's apples and oranges though, av companies won't be competitors until they start offering whitelist technology of their own... what's so misguided about this, though, is that if they actually manage to take av's place on peoples' desktops they're ultimately going to wind up also taking av's place in peoples' cross-hairs... if they displace anti-virus then people will necessarily become just as disenfranchised with whitelisting as they are with anti-virus because whitelisting has failings too...
in the comments robin does admit that whitelisting won't stand on it's own and that additional technologies will be needed to complement it but weasels out of saying what... i suspect intuitively he knows the answer: at the highest, most abstract level, what complements a whitelist? that's right, a blacklist... though he expressly derides the idea as "positioning" in his article and says that you should nevermind it, the fact is that known malware scanning and application whitelisting are natural companions...
i want to call robin bloor a troll, i really do, but if he's being funded by whitelisting companies then what he really is is a shill... either way, i'm done with him - when my arguments (and most other peoples' arguments) now are the same ones i posted if march of '06 there really is little point in continuing with this... besides, considering the uptick i get in hits based on searches involving the term whitelist when he posts more nonsense, i'm pretty sure the counter-arguments are being heard without additional effort on my part so i can put that you are being trolled feeling to rest...
i haven't really seen much new material that i didn't cover myself in that first response - exotic execution, accuracy of local whitelist management, and scalability of global whitelist management are all outstanding problems with whitelisting... finding out that the whitelist vendors themselves admit to the unmanageable scope of their own efforts is one of the few new things that have come up since then...
robin doesn't address any of this, of course, and like the emperor's new clothes there really isn't anything there in his new article... 2 whitelist companies merged and became bigger than either was before - big woop...
the only interesting things were the comments on the register's mirror of the article... vesselin bontchev hit the nail on the head several times (and i'd expect nothing less, though i wouldn't have expected vess to be first to post on the register - ugh), but what interested me most was the suggestion that robin bloor's 'research' is funded by the whitelist industry...
clearly this would be some segment of the whitelist industry that is misguided enough to think that anti-virus companies are actually their competitors... it's apples and oranges though, av companies won't be competitors until they start offering whitelist technology of their own... what's so misguided about this, though, is that if they actually manage to take av's place on peoples' desktops they're ultimately going to wind up also taking av's place in peoples' cross-hairs... if they displace anti-virus then people will necessarily become just as disenfranchised with whitelisting as they are with anti-virus because whitelisting has failings too...
in the comments robin does admit that whitelisting won't stand on it's own and that additional technologies will be needed to complement it but weasels out of saying what... i suspect intuitively he knows the answer: at the highest, most abstract level, what complements a whitelist? that's right, a blacklist... though he expressly derides the idea as "positioning" in his article and says that you should nevermind it, the fact is that known malware scanning and application whitelisting are natural companions...
i want to call robin bloor a troll, i really do, but if he's being funded by whitelisting companies then what he really is is a shill... either way, i'm done with him - when my arguments (and most other peoples' arguments) now are the same ones i posted if march of '06 there really is little point in continuing with this... besides, considering the uptick i get in hits based on searches involving the term whitelist when he posts more nonsense, i'm pretty sure the counter-arguments are being heard without additional effort on my part so i can put that you are being trolled feeling to rest...
Tuesday, June 26, 2007
looking for security wizards
well what do you know, the agnitum folks have come up with a quiz to test your security smarts...
25 out of 30 on my first try... that's 25 correct guesses at what the agnitum folks thought were the right answers since many of the questions didn't seem to include the right answers as far as i could tell - for example, since when is self-replication not the thing that most precisely characterizes a computer virus? this is a quiz to determine who's a security wizard, right? sure average folks might not be expected to know such details but we're talking about wizards here...
then there's question about what cannot be spyware that was accompanied by nothing but options that could be considered spyware... yes, it's possible to have self-replicating spyware (malware categories are not mutually exclusive), yes it's possible to have spyware that changes your browser's start page (otherwise spyware authors would just throw in that one extra feature to avoid having their creations labeled as spyware), and yes a keylogger is most definitely a kind of spyware (what, you think keeping track of what keys you typed and sending them to a 3rd party doesn't count as spying?)...
the quiz also doesn't tell you which questions you got wrong or what the right answers were so it doesn't really help the non-wizards learn and advance themselves... i actually think the underlying idea behind the quiz is a good one, but not if people can't learn from it...
then again, maybe they're just looking for security wizards to help them write a better quiz...
 |
| Are You an Internet Security Wizard? |
25 out of 30 on my first try... that's 25 correct guesses at what the agnitum folks thought were the right answers since many of the questions didn't seem to include the right answers as far as i could tell - for example, since when is self-replication not the thing that most precisely characterizes a computer virus? this is a quiz to determine who's a security wizard, right? sure average folks might not be expected to know such details but we're talking about wizards here...
then there's question about what cannot be spyware that was accompanied by nothing but options that could be considered spyware... yes, it's possible to have self-replicating spyware (malware categories are not mutually exclusive), yes it's possible to have spyware that changes your browser's start page (otherwise spyware authors would just throw in that one extra feature to avoid having their creations labeled as spyware), and yes a keylogger is most definitely a kind of spyware (what, you think keeping track of what keys you typed and sending them to a 3rd party doesn't count as spying?)...
the quiz also doesn't tell you which questions you got wrong or what the right answers were so it doesn't really help the non-wizards learn and advance themselves... i actually think the underlying idea behind the quiz is a good one, but not if people can't learn from it...
then again, maybe they're just looking for security wizards to help them write a better quiz...
the end of an era
since i'm generally known for being blunt anyways i'll get right to the point - comp.virus is gone...
of course, in any practical sense comp.virus has been gone for a good long time, but even after all this time i've kept my newsreader subscribed to the group hoping it would eventually come back... it's finally time to remove the subscription - the group itself was slated for removal on june 25 2007...
i have fond memories of the group - back before i even got on the internet i read comp.virus thanks to an internet<->fidonet gateway... what i found was a place with a lot of knowledgeable people talking about exactly the kind of thing i wanted to read about - viruses... oh sure, there was the fido VIRUS and VIRUS_INFO echos (in fact those still exist, though they're mostly unused now-a-days) but i wanted more...
of course it wasn't long after i found comp.virus that it fell out of use (for reasons that nick fitzgerald has probably explained too many times already) and alt.comp.virus was used as a substitute (which proved interesting for all sorts of reasons)... alt.comp.virus (and the more recent alt.comp.anti-virus) are unmoderated, however, and without that control over the quality of the content most of those knowledgeable folks i was introduced to first in comp.virus and then in alt.comp.virus eventually moved on to less noisy pursuits...
i guess the good old days have been gone for a long time, but the removal of comp.virus is like going back to your old neighborhood and discovering one of your favourite spots has been turned into a parking lot...
oh well, we still have the FAQ i guess...
of course, in any practical sense comp.virus has been gone for a good long time, but even after all this time i've kept my newsreader subscribed to the group hoping it would eventually come back... it's finally time to remove the subscription - the group itself was slated for removal on june 25 2007...
i have fond memories of the group - back before i even got on the internet i read comp.virus thanks to an internet<->fidonet gateway... what i found was a place with a lot of knowledgeable people talking about exactly the kind of thing i wanted to read about - viruses... oh sure, there was the fido VIRUS and VIRUS_INFO echos (in fact those still exist, though they're mostly unused now-a-days) but i wanted more...
of course it wasn't long after i found comp.virus that it fell out of use (for reasons that nick fitzgerald has probably explained too many times already) and alt.comp.virus was used as a substitute (which proved interesting for all sorts of reasons)... alt.comp.virus (and the more recent alt.comp.anti-virus) are unmoderated, however, and without that control over the quality of the content most of those knowledgeable folks i was introduced to first in comp.virus and then in alt.comp.virus eventually moved on to less noisy pursuits...
i guess the good old days have been gone for a long time, but the removal of comp.virus is like going back to your old neighborhood and discovering one of your favourite spots has been turned into a parking lot...
oh well, we still have the FAQ i guess...
Monday, June 18, 2007
100% virus-free... again...
well, the marketroids are at it again and this time they work for panda software:
y'know, if it wasn't for that 'absolute protection' bit (that sounds familiar), i might have believed they had the best of intentions at heart and simply meant that they'd give you your money back if they failed to keep the viruses out (not that that will necessarily compensate a business for the cost they'll incur when malware slips through and their guard was down due to a false sense of security)... not unlike the marketing message i knocked messagelabs for years ago (in fact, the service being offered doesn't sound fundamentally different either)...
even if i were inclined to believe they had the best intentions, the road to hell is paved with such intentions... consider how the message has evolved as it's traveled, first to yahoo finance
100% virus-free (aka 100% protection) are the magic words you do not say, it's the promise you do not make... this is why i distrust marketing: not only do they generally not really know they technology they're selling but, as this example indicates, they often don't know the business/industry either.... i've said it before, i'll say it again; 100% protection / 100% virus-free is the archetype for anti-virus snake oil and there really is no excuse for it anymore... somebody failed anti-virus marketing 101...
as always, vote with your wallet... if you want intellectually honest av vendors, market pressure is the tool you need to use...
SLA (Service Level of Agreement): 100% virus-free guarantee.and
Together with quarantine management, this enables absolute protection against viruses, worms and Trojans. We are committed to offering a 100% virus-free service.and once more for the trifecta
With respect to the antivirus filtering service, TrustLayer offers a 100% virus-free contractual guarantee.
y'know, if it wasn't for that 'absolute protection' bit (that sounds familiar), i might have believed they had the best of intentions at heart and simply meant that they'd give you your money back if they failed to keep the viruses out (not that that will necessarily compensate a business for the cost they'll incur when malware slips through and their guard was down due to a false sense of security)... not unlike the marketing message i knocked messagelabs for years ago (in fact, the service being offered doesn't sound fundamentally different either)...
even if i were inclined to believe they had the best intentions, the road to hell is paved with such intentions... consider how the message has evolved as it's traveled, first to yahoo finance
Panda Software guarantees that email filtered through TrustLayer will be 100% free of virus.and then from there to the daily incite
What's old is new again. Panda guarantees 100% virus-free email. Join the club, the other email security services have been doing this for years. And how do you prove it anyway?mike rothman at least knows to take this with a grain of salt but not everyone is as savvy - who knows what other paths it's taken and what false impressions it's given...
100% virus-free (aka 100% protection) are the magic words you do not say, it's the promise you do not make... this is why i distrust marketing: not only do they generally not really know they technology they're selling but, as this example indicates, they often don't know the business/industry either.... i've said it before, i'll say it again; 100% protection / 100% virus-free is the archetype for anti-virus snake oil and there really is no excuse for it anymore... somebody failed anti-virus marketing 101...
as always, vote with your wallet... if you want intellectually honest av vendors, market pressure is the tool you need to use...
Sunday, June 17, 2007
and then hell froze over
anti-virus companies do not hire virus writers, if i've said it once i've said it a thousand times... oh sure, there was that one example where a company which wasn't even in the security industry (their main focus being graphics) hired benny (aka marek strihavka) to be the lead developer of their anti-virus software (which wasn't actually for public consumption at the time) because they felt he was reformed (even though he still makes viruses available on his webpage) and was then thoroughly denounced by multliple members of the av industry... then, of course, there's the case of sven jaschan who was hired by a security company - but again NOT an anti-virus company or even a company looking to make anti-virus software, so one could say that he doesn't count (especially since his hiring resulted in the company losing an av company it had hoped to partner with)...
it may seem like these violate the av companies don't hire virus writers rule but in reality these edge cases (neither company is technically an anti-virus company) actually reinforce the rule by virtue of what the av industry does in response...
so you can imagine, then, how far my jaw dropped when john sharp, founder of authentium, solicited applications from students who graduated from a virus writing curriculum:
now, i realize one might argue that people who learned to write viruses in school don't have the same motives as those who write and release viruses (though it occurs to me that a virus writing curriculum would appeal to exactly the type of person who would write and release viruses so you may actually be dealing with a population whose bad apple content is higher than average) and the debate has been weighed in on by far more influential individuals than myself - but, with many companies refusing to hire such students just as they would virus writers, mr. sharp's words are unexpected to say the least... i wonder if he's shared his philosophy with helmuth freericks, who was listed as the vp of r&d at authentium when he signed the public letter against teaching virus writing that's being hosted by the anti-virus information exchange network...
things get more interesting than that, however... authentium's (formerly command software system's) command anti-virus used to license the f-prot scanning engine and given the identical naming produced by the two it seems like it still does... that engine is produced by frisk software international... frisk has made his feelings on the subject of virus writing curricula very clear, stating that it's ethically unacceptable, so it'll be interesting to see what if anything becomes of this if authentium really does hire students who've taken such courses...
it may seem like these violate the av companies don't hire virus writers rule but in reality these edge cases (neither company is technically an anti-virus company) actually reinforce the rule by virtue of what the av industry does in response...
so you can imagine, then, how far my jaw dropped when john sharp, founder of authentium, solicited applications from students who graduated from a virus writing curriculum:
Authentium to George Ledin's students: if you're interested in a job, we'll look at your resume. Based on your training, our assumption is that you're going to do a better job helping us detect and defeat malware than someone without this knowledge.
now, i realize one might argue that people who learned to write viruses in school don't have the same motives as those who write and release viruses (though it occurs to me that a virus writing curriculum would appeal to exactly the type of person who would write and release viruses so you may actually be dealing with a population whose bad apple content is higher than average) and the debate has been weighed in on by far more influential individuals than myself - but, with many companies refusing to hire such students just as they would virus writers, mr. sharp's words are unexpected to say the least... i wonder if he's shared his philosophy with helmuth freericks, who was listed as the vp of r&d at authentium when he signed the public letter against teaching virus writing that's being hosted by the anti-virus information exchange network...
things get more interesting than that, however... authentium's (formerly command software system's) command anti-virus used to license the f-prot scanning engine and given the identical naming produced by the two it seems like it still does... that engine is produced by frisk software international... frisk has made his feelings on the subject of virus writing curricula very clear, stating that it's ethically unacceptable, so it'll be interesting to see what if anything becomes of this if authentium really does hire students who've taken such courses...
Thursday, June 14, 2007
when misunderstanding hurts you
today's post by tyler reguly about a revelation he found in f-secure's marketing message caught my eye because i think it exhibits some misunderstandings that i suspect are probably not unique to him so i'm going to try and clear up some of the confusion...
the statement that triggered all of this was that f-secure ships out around 6 updates per day... in tyler's words:
the key misunderstanding here is what exactly those threat write-ups represent... they are not the only pieces of malware that the respective av companies encounter, far from it, they are just the ones that have distinguished themselves enough from the background noise of hundreds of pieces of malware being processed per day to warrant a write-up... nobody maintains a repository of malware write-ups equal in quantity to the amount of malware their product detects, that's just too much work for too little return, so they pick out the ones that are significant in some way such as ones that do something genuinely new, or ones that have in hindsight proven to be a slightly more significant threat than the vast majority...
notice the word hindsight... it is, unfortunately, not possible to predict which pieces of malware will make it big and which won't so it's not possible to use that as a criteria for issuing an update... technically sophisticated viruses have gone nowhere while barely functioning frankenstein creations have run amok... as such, all the anti-virus companies can do is try to minimize (within reason) the window of opportunity that a potentially significant threat will have... in fact, sometimes the failure to become a significant threat (certainly a desirable outcome) hinges on the rapid and widespread deployment of detection capabilities for it...
f-secure accomplishes this with around 6 updates per day... some companies ship updates hourly (and have been doing so for years now)... these aren't fixes (at least not generally), it's not a QA problem, there genuinely are sufficiently many pieces of malware being processed each day to warrant this update frequency... does that mean they're sweating the small stuff? maybe so but it's only because there's no way to know what's going to become big...
the statement that triggered all of this was that f-secure ships out around 6 updates per day... in tyler's words:
When you are pushing out that many updates it tells me one of two things. i) You are “sweatin’ the small stuff” or ii) You have a bad QA process and need to push out fixes.he goes on to investigate whether there is enough malware to justify that many updates and finds that no-one is producing write-ups of new threats at anywhere near that rate...
the key misunderstanding here is what exactly those threat write-ups represent... they are not the only pieces of malware that the respective av companies encounter, far from it, they are just the ones that have distinguished themselves enough from the background noise of hundreds of pieces of malware being processed per day to warrant a write-up... nobody maintains a repository of malware write-ups equal in quantity to the amount of malware their product detects, that's just too much work for too little return, so they pick out the ones that are significant in some way such as ones that do something genuinely new, or ones that have in hindsight proven to be a slightly more significant threat than the vast majority...
notice the word hindsight... it is, unfortunately, not possible to predict which pieces of malware will make it big and which won't so it's not possible to use that as a criteria for issuing an update... technically sophisticated viruses have gone nowhere while barely functioning frankenstein creations have run amok... as such, all the anti-virus companies can do is try to minimize (within reason) the window of opportunity that a potentially significant threat will have... in fact, sometimes the failure to become a significant threat (certainly a desirable outcome) hinges on the rapid and widespread deployment of detection capabilities for it...
f-secure accomplishes this with around 6 updates per day... some companies ship updates hourly (and have been doing so for years now)... these aren't fixes (at least not generally), it's not a QA problem, there genuinely are sufficiently many pieces of malware being processed each day to warrant this update frequency... does that mean they're sweating the small stuff? maybe so but it's only because there's no way to know what's going to become big...
Monday, June 11, 2007
the slow death of someone's credibility
robin bloor doesn't show up on my radar very often, but when he does it always seems to be about how anti-virus is dead, dying, or doomed in some way... this time it's about the slow death of anti-virus technology...
dave lewis thought it worth pointing to (thus leading to the blip on my radar) and the folks over on the authentium blog went against their better instincts and actually responded to it...
it's a good response, too, and it touches on a point i've also made about whitelisting - specifically that the numbers of good programs (ie. those that would be put on the vendor supplied whitelist) far exceed those of malware... why this is interesting is because one of the main arguments against anti-virus technology is a fundamental disdain for enumerating bad things on the premise of it being too big of a problem... clearly, if enumerating good things is several orders of magnitude harder than enumerating bad things then this particular argument is garbage... it's nice to see that a whitelist vendor is owning up to the enumeration cost, even if some whitelist proponents are unwilling... to the unwilling i would say imagine if the TSA used a whitelist instead of a blacklist - do you think telling most people they can't fly because they aren't on the fly list would work better than telling a few people they can't fly because they are on the no-fly list?...
this time around mr. bloor wants us to believe that, because whitelisting is gaining traction in the market, his prognostications about whitelisting replacing blacklisting are gradually coming true... seemingly choosing not to consider the possibility that the trends he's noticed are nothing more than the maturation of the whitelisting market, and unperturbed by history's numerous examples of the av industry adding technologies to their portfolios rather than replacing the old with the new, mr. bloor's arguments seem rather ridiculous...
but then again, they're coming from the same guy who thinks traditional polymorphism and server-side polymorphism are comparable - that because traditional polymorphism (where the transformation function responsible for the polymorphism is carried with the self-replicating malware and therefore open to attack by the av'ers) has been around for 16 years that the av industry should have developed something capable of dealing with the newly emerged server-side polymorphism (where the transformation function isn't carried by the malware and thus isn't generally open to attack) by now...
so should anyone take him seriously when he says whitelisting is better than av and that it's going to replace av? no, because whitelists are not going to replace blacklists, whitelists aren't better than blacklists, they're just different from blacklists... whitelists don't have the same weaknesses blacklists do just as blacklists don't have the same weaknesses that whitelists do... the notion that we would or should use only one type of technology to protect ourselves from malware is antiquated and fundamentally broken - there is no silver bullet, no panacea, and if you don't employ a multi-layered strategy (aka defense in depth) then you're just setting yourself up for unnecessary failure... i have to wonder, when av technology is still here 10 years from now, will robin bloor be eating crow or will he still be forecasting av's death like some inverted version of monty python's parrot skit...
dave lewis thought it worth pointing to (thus leading to the blip on my radar) and the folks over on the authentium blog went against their better instincts and actually responded to it...
it's a good response, too, and it touches on a point i've also made about whitelisting - specifically that the numbers of good programs (ie. those that would be put on the vendor supplied whitelist) far exceed those of malware... why this is interesting is because one of the main arguments against anti-virus technology is a fundamental disdain for enumerating bad things on the premise of it being too big of a problem... clearly, if enumerating good things is several orders of magnitude harder than enumerating bad things then this particular argument is garbage... it's nice to see that a whitelist vendor is owning up to the enumeration cost, even if some whitelist proponents are unwilling... to the unwilling i would say imagine if the TSA used a whitelist instead of a blacklist - do you think telling most people they can't fly because they aren't on the fly list would work better than telling a few people they can't fly because they are on the no-fly list?...
this time around mr. bloor wants us to believe that, because whitelisting is gaining traction in the market, his prognostications about whitelisting replacing blacklisting are gradually coming true... seemingly choosing not to consider the possibility that the trends he's noticed are nothing more than the maturation of the whitelisting market, and unperturbed by history's numerous examples of the av industry adding technologies to their portfolios rather than replacing the old with the new, mr. bloor's arguments seem rather ridiculous...
but then again, they're coming from the same guy who thinks traditional polymorphism and server-side polymorphism are comparable - that because traditional polymorphism (where the transformation function responsible for the polymorphism is carried with the self-replicating malware and therefore open to attack by the av'ers) has been around for 16 years that the av industry should have developed something capable of dealing with the newly emerged server-side polymorphism (where the transformation function isn't carried by the malware and thus isn't generally open to attack) by now...
so should anyone take him seriously when he says whitelisting is better than av and that it's going to replace av? no, because whitelists are not going to replace blacklists, whitelists aren't better than blacklists, they're just different from blacklists... whitelists don't have the same weaknesses blacklists do just as blacklists don't have the same weaknesses that whitelists do... the notion that we would or should use only one type of technology to protect ourselves from malware is antiquated and fundamentally broken - there is no silver bullet, no panacea, and if you don't employ a multi-layered strategy (aka defense in depth) then you're just setting yourself up for unnecessary failure... i have to wonder, when av technology is still here 10 years from now, will robin bloor be eating crow or will he still be forecasting av's death like some inverted version of monty python's parrot skit...
Subscribe to:
Posts (Atom)