(well, looks like i'm going to add to the noise about the secunia test... it's already been discussed on the security fix blog, eset's threatblog, the register, the sunbelt software blog, the panda security blog, and the zero day blog)
so secunia did a test with exploits they developed in the lab and found that av products sucked...
well gee, doesn't that sound an awful lot like the consumer reports test? if you don't make the distinction that exploits are a special case of malware then there would really be no difference between this and that terrible consumer reports test where they paid to have 5000 new pieces of malware created...
but exploit code is a special case, we need to create benign exploits, we need to be able to use them in order to determine whether our systems are vulnerable, whether the patches that supposedly fix the vulnerability have been applied properly, whether they truly fix the vulnerability, etc...
so then this test was alright then, right? nope, not by a long shot... first and foremost is the idea that anti-virus/anti-malware products should detect these lab-grown exploits in the first place... the issue is not so much that av is only in the business of detecting malicious software, it's that there are very good reasons why av can't and shouldn't be detecting benign exploits... as i just got finished saying, we need those exploits, we need to be able to use them, but how are you supposed to do that if your anti-virus is blocking access to them? it's one thing to use a benign exploit to test the vulnerable surface area of your systems, it's another thing altogether to turn off your security software to do so... there are a variety of technical, logistical, and legal reasons why anti-malware must be constrained to detecting only those things with a proven malicious pedigree, and if people don't like that it's just too bad - get over it, those reasons aren't going away just because they don't mesh with your ideology... either exploits are legitimate and necessary, in which case anti-malware apps shouldn't be alarming on them because it interferes with the proper use of exploits, or they aren't, in which case secunia acted in bad faith by creating new malware - secunia can't have their cake and eat it too...
the next problem was this notion of detecting exploitation... read that carefully - "detecting exploitation"... is exploitation a thing? no, it's a behaviour, and despite certain claims from various companies about dynamic behaviour-based heuristics, known-malware scanners (and by all indications that's the only part of the security suites secunia actually tested, begging the question why they bothered with the suites at all - incompetence maybe?) are built to detect bad actors not bad actions... that's not to say anti-malware companies don't have offerings to detect and even block bad or unauthorized behaviour, they do have HIPS offerings, but it's fundamentally different technology from what people are accustomed to with anti-malware and it's not always simple to setup/maintain properly so they don't necessarily bundle it with their anti-malware products or even in their internet security suites...
speaking of the distinction between actors and actions, that confusion seemed to be rooted in the use of the term "threat"... i have in the past remarked that "threat" is a bit of an ambiguous term where all kinds of things with "threat" in their name get called simply threats... in this case in particular, anti-malware apps use the term "threat" as a short form of "threat agent" (which is actually one of the more common things that "threat" is used to represent)... exploitation isn't an agent by any stretch of the imagination but because everything gets called simply a "threat" those who don't really understand what's going on (which surprisingly seems to include the folks at secunia) will treat all usages of the term the same and not realize that anti-malware scanners are only designed to catch some of the things that get called "threat"...
of course, a post on this site wouldn't be complete without pointing out the conflict of interest that is also present in this test... secunia's business is about vulnerabilities and exploits - they have a paid product for detecting vulnerable software (a different approach to the same ends as trying to catch/block the exploits) so it's in their financial best interests to publish a test that makes the anti-malware industry look bad (aka FUD) and the exploit problem look important (in other words, hyping up the problem)... it's a classic self-serving study and one wonders if the people responsible think the rest of us were born yesterday...
devising a framework for thinking about malware and related issues such as viruses, spyware, worms, rootkits, drm, trojans, botnets, keyloggers, droppers, downloaders, rats, adware, spam, stealth, fud, snake oil, and hype...
Tuesday, October 14, 2008
Wednesday, October 08, 2008
what i did on my sector vacation
well, today was the second/last day of sector '08 and now that it's over i figure i might as well write about my experience there... i don't do a lot of these sorts of posts primarily because i don't go to a lot of security conferences (the only other one i've been to was rsa '02) but since i'd heard good things about the last sector and since it is practically in my back yard (well, ok, it's approximately 1.5 hours away on public transit) i didn't feel all that guilty about broaching the subject with the higher-ups at work (the smaller price tag helps too)... it came at a pretty hectic time for me at work, but thankfully i was still able to attend...
the opening keynote of the first day was with the royal canadian mounted police; it was pretty dry - unless you're a fan of alphabet soup, there were a lot of acronyms that i had never heard before and i'm sure i'll never hear again...
the first talk i went to after that was kevvie (kevvie?) fowler's sql rootkits and encryption presentation... this was an excellent talk if for no other reason than it gave me information i can put to direct use when i get to work tomorrow (awesome - instant value for my employers in the first session of the first day)... it was also a pretty good at not misusing the term rootkit as so many others are want to do these days...
the lunch panel was unfortunately not all that memorable for me... maybe i was too busy eating or maybe the people talking just had too short a period in which to make a lasting impression, i dunno... maybe i'm just not a panel person...
the second talk i attended was jay beale's middler presentation... once again possible value for my employer, at least possibly... it's an unsettling realization that there's now an automated tool that can affect confidentiality, availability, and integrity of web data (by virtue of allowing an attacker to read, withhold, or even modify your data) basically if any part of your session happens outside of ssl...
next up for me was bruce potter's presentation on novel malware detection... now i admit this one was for me and not my employers - the first two sessions where the only ones where i could find that looked like they might touch anything relating to work so from here out it's purely for my own interest... bruce was a very entertaining speaker, however he got on a bit of an anti-av rant that wasn't really part of his presentation (that dealt more with detecting anomalous network activity by analyzing logs)... i just rolled my eyes at the rant - i considered saying something, but since 'the hoff' was just across the aisle and 1 row back i felt certain it would have resulted in smack upside the head and instructions to stop being such a jerk... ok, not really, but an in-person presentation is a very different forum from the online kind (where perhaps i'm known for being a jerk) in a number of ways, not the least of which being time constraints, and had no desire to sabotage the presentation (though as for that the length of the rant did that slightly anyways since bruce wound up running out of time)...
the final talk i attended the first day was matt sergeant's presentation on tracking current and future botnets... there was a fair bit of interesting details about current and past botnets, about their sizes and how those metrics were generated, about characteristics unique to the emails sent by each, etc., but matt (like bruce potter before) got a little anti-av saying they needed a kick in the butt about detecting those emails... my knee-jerk reaction (all internal because i didn't want to sabotage this talk either) was that av is in the business of detecting malicious code not emails generated by malicious code, but as i let that stew for a while i realized 2 things... the first was that that was remarkably like something i said back in the mid-to-late 90's about av software not detecting trojans... not that i thought they shouldn't detect trojans, but just that it was a defensible position to take - obviously detecting trojans was better than not doing so and i'm glad they started but there was a time when anti-virus software was literally just anti-virus... now that it's morphed into anti-malware it's once again defensible to say that detecting something that isn't malware (and emails aren't) is outside av's scope but (and this is the second thing i realized) the users would be better served and better protected if av did detect these things - it would serve as a negative control on a botnet's ability to acquire new nodes (at least until the bot designer change's the smtp footprint/fingerprint of the bot)...
so in that respect i think i'll agree with matt sergeant that av could be and perhaps should be doing more... his misapplication of a sophos graph of malware prevalence, however, i won't agree with... he really, really ought to know better than to try to compare a botnet's size with entries on a malware prevalence table... here's why it just doesn't work: a malware prevalence table breaks down malware prevalence on a per variant basis while botnets today are generally heterogeneous from a variant perspective (which is to say there are many times many different variants of a particular family of malware in any given botnet thanks to things like server-side polymorphism) so while a botnet may be huge, the prevalence of any particular variant in that botnet's ecology is still probably pretty low... that being said, something i've been mulling over in my mind for a little while now is whether prevalence tables broken down by family instead of variant are the more interesting metric these days in light of botnets and malware campaigns in general... personally, i'd like to see both types of tables...
the opening keynote for day two was with stephen toulouse and had the best opening ever ([looks at giant screen] 'dear lord, is that what i look like' - or something to that effect)... stepto thinks us security folks can bring some valuable insights and thought patterns to fields outside of security - i certainly hope so, i'm in software development and while i'm not high enough up the food chain to make the big decisions (and frankly don't want to be) i have been able to direct some things which i hope have been of benefit...
the first talk i went to on the second day was deviant ollam's presentation on lockpicking... i found the lockpicking at sector absolutely fascinating, both in this talk and also in the lockpick village... perhaps it goes back to me breaking into my own home as a kid when i (frequently) lost/forgot my keys, but i just went into sponge mode and absorbed as much as i possibly could... i imagine there were a lot of questions about dudley combination locks since that seems to be what we have up here in place of master combination locks and since they aren't exactly the same (our dials go up to 60, so there)... one of these days i should really put in some time and try to see if i can brute force a dudley lock combination because i have 4 here but only one with a known combination...
day 2's lunch keynote was johnny long's presentation on no-tech hacking... it was very entertaining to see the scope of the average (and often not-so-average) person's obliviousness to security concepts, but it was also a little disheartening especially when he ended the presentation without offering any hope for change... i think we all know there's a scarcity of security awareness in the general population, that's one of the reasons why i started looking into whether memetic engineering might be able to help things along (re: secmeme.com)... if only i had time to work on all the things i want to do (though i'm sure johnny's talk will provide a wealth of inspiration for the security idiot meme)...
the next talk i attended was james arlen's security heretic presentation... this presentation was in a rather unfortunate time slot, since chris hoff's virtualization presentation was going on at the same time (i thought of going to that one but really, the only thing i use virtualization for is sandboxing)... this was also the presentation that seemed to get the least amount of respect from attendees as people were constantly coming and going (and i picked a seat near the door, uggh!)... unfortunately it was also not the talk i was expecting it to be... while i was expecting to hear about one security pro's journey (as the description suggested) what i got instead was a very large number of calls for a show of hands... i'm sure it all makes sense to people who have been in similar positions but for someone like me who hasn't it just doesn't help me relate...
the last talk i went to was jason wright's presentation on finding cryptography in object code... strangely enough, i went to a talk on the same subject at rsa '02 where they talked about finding magic constants... jason lead off with that (which made me a little bit nervous) but that was only for context as the meat of the presentation was more about frequency of occurrence of operations usually only seen in crypto which was interesting... it also wound up being the shortest talk i saw...
and then it ended, and we gathered for one last time in the keynote/lunch hall, i interrupted hoff fulfilling his security rockstar duties to say hi (sorry i didn't see you later when everyone made for the door, chris, i did look though but i'm sure you'd already attracted another crowd), and then they handed out prizes (prizes! i don't remember that at rsa) and it was done... it was a great experience, i enjoyed the talks a lot, i didn't network as much as i probably should have ('cause i generally suck at that) but oh well, at least i can put some more faces to familiar names now - perhaps if the next time is soon enough (ie. not 6 years in the future) i'll be able to put that to good use...
the opening keynote of the first day was with the royal canadian mounted police; it was pretty dry - unless you're a fan of alphabet soup, there were a lot of acronyms that i had never heard before and i'm sure i'll never hear again...
the first talk i went to after that was kevvie (kevvie?) fowler's sql rootkits and encryption presentation... this was an excellent talk if for no other reason than it gave me information i can put to direct use when i get to work tomorrow (awesome - instant value for my employers in the first session of the first day)... it was also a pretty good at not misusing the term rootkit as so many others are want to do these days...
the lunch panel was unfortunately not all that memorable for me... maybe i was too busy eating or maybe the people talking just had too short a period in which to make a lasting impression, i dunno... maybe i'm just not a panel person...
the second talk i attended was jay beale's middler presentation... once again possible value for my employer, at least possibly... it's an unsettling realization that there's now an automated tool that can affect confidentiality, availability, and integrity of web data (by virtue of allowing an attacker to read, withhold, or even modify your data) basically if any part of your session happens outside of ssl...
next up for me was bruce potter's presentation on novel malware detection... now i admit this one was for me and not my employers - the first two sessions where the only ones where i could find that looked like they might touch anything relating to work so from here out it's purely for my own interest... bruce was a very entertaining speaker, however he got on a bit of an anti-av rant that wasn't really part of his presentation (that dealt more with detecting anomalous network activity by analyzing logs)... i just rolled my eyes at the rant - i considered saying something, but since 'the hoff' was just across the aisle and 1 row back i felt certain it would have resulted in smack upside the head and instructions to stop being such a jerk... ok, not really, but an in-person presentation is a very different forum from the online kind (where perhaps i'm known for being a jerk) in a number of ways, not the least of which being time constraints, and had no desire to sabotage the presentation (though as for that the length of the rant did that slightly anyways since bruce wound up running out of time)...
the final talk i attended the first day was matt sergeant's presentation on tracking current and future botnets... there was a fair bit of interesting details about current and past botnets, about their sizes and how those metrics were generated, about characteristics unique to the emails sent by each, etc., but matt (like bruce potter before) got a little anti-av saying they needed a kick in the butt about detecting those emails... my knee-jerk reaction (all internal because i didn't want to sabotage this talk either) was that av is in the business of detecting malicious code not emails generated by malicious code, but as i let that stew for a while i realized 2 things... the first was that that was remarkably like something i said back in the mid-to-late 90's about av software not detecting trojans... not that i thought they shouldn't detect trojans, but just that it was a defensible position to take - obviously detecting trojans was better than not doing so and i'm glad they started but there was a time when anti-virus software was literally just anti-virus... now that it's morphed into anti-malware it's once again defensible to say that detecting something that isn't malware (and emails aren't) is outside av's scope but (and this is the second thing i realized) the users would be better served and better protected if av did detect these things - it would serve as a negative control on a botnet's ability to acquire new nodes (at least until the bot designer change's the smtp footprint/fingerprint of the bot)...
so in that respect i think i'll agree with matt sergeant that av could be and perhaps should be doing more... his misapplication of a sophos graph of malware prevalence, however, i won't agree with... he really, really ought to know better than to try to compare a botnet's size with entries on a malware prevalence table... here's why it just doesn't work: a malware prevalence table breaks down malware prevalence on a per variant basis while botnets today are generally heterogeneous from a variant perspective (which is to say there are many times many different variants of a particular family of malware in any given botnet thanks to things like server-side polymorphism) so while a botnet may be huge, the prevalence of any particular variant in that botnet's ecology is still probably pretty low... that being said, something i've been mulling over in my mind for a little while now is whether prevalence tables broken down by family instead of variant are the more interesting metric these days in light of botnets and malware campaigns in general... personally, i'd like to see both types of tables...
the opening keynote for day two was with stephen toulouse and had the best opening ever ([looks at giant screen] 'dear lord, is that what i look like' - or something to that effect)... stepto thinks us security folks can bring some valuable insights and thought patterns to fields outside of security - i certainly hope so, i'm in software development and while i'm not high enough up the food chain to make the big decisions (and frankly don't want to be) i have been able to direct some things which i hope have been of benefit...
the first talk i went to on the second day was deviant ollam's presentation on lockpicking... i found the lockpicking at sector absolutely fascinating, both in this talk and also in the lockpick village... perhaps it goes back to me breaking into my own home as a kid when i (frequently) lost/forgot my keys, but i just went into sponge mode and absorbed as much as i possibly could... i imagine there were a lot of questions about dudley combination locks since that seems to be what we have up here in place of master combination locks and since they aren't exactly the same (our dials go up to 60, so there)... one of these days i should really put in some time and try to see if i can brute force a dudley lock combination because i have 4 here but only one with a known combination...
day 2's lunch keynote was johnny long's presentation on no-tech hacking... it was very entertaining to see the scope of the average (and often not-so-average) person's obliviousness to security concepts, but it was also a little disheartening especially when he ended the presentation without offering any hope for change... i think we all know there's a scarcity of security awareness in the general population, that's one of the reasons why i started looking into whether memetic engineering might be able to help things along (re: secmeme.com)... if only i had time to work on all the things i want to do (though i'm sure johnny's talk will provide a wealth of inspiration for the security idiot meme)...
the next talk i attended was james arlen's security heretic presentation... this presentation was in a rather unfortunate time slot, since chris hoff's virtualization presentation was going on at the same time (i thought of going to that one but really, the only thing i use virtualization for is sandboxing)... this was also the presentation that seemed to get the least amount of respect from attendees as people were constantly coming and going (and i picked a seat near the door, uggh!)... unfortunately it was also not the talk i was expecting it to be... while i was expecting to hear about one security pro's journey (as the description suggested) what i got instead was a very large number of calls for a show of hands... i'm sure it all makes sense to people who have been in similar positions but for someone like me who hasn't it just doesn't help me relate...
the last talk i went to was jason wright's presentation on finding cryptography in object code... strangely enough, i went to a talk on the same subject at rsa '02 where they talked about finding magic constants... jason lead off with that (which made me a little bit nervous) but that was only for context as the meat of the presentation was more about frequency of occurrence of operations usually only seen in crypto which was interesting... it also wound up being the shortest talk i saw...
and then it ended, and we gathered for one last time in the keynote/lunch hall, i interrupted hoff fulfilling his security rockstar duties to say hi (sorry i didn't see you later when everyone made for the door, chris, i did look though but i'm sure you'd already attracted another crowd), and then they handed out prizes (prizes! i don't remember that at rsa) and it was done... it was a great experience, i enjoyed the talks a lot, i didn't network as much as i probably should have ('cause i generally suck at that) but oh well, at least i can put some more faces to familiar names now - perhaps if the next time is soon enough (ie. not 6 years in the future) i'll be able to put that to good use...
Tags:
sector conference
Saturday, October 04, 2008
do we really need anti-virus
thanks to alan shimel for pointing out this post by kai roer asking if we need anti-virus in 2008...
alan is right, of course, that anti-virus does a lot more than just catch viruses these days, and that anti-virus helps control older virus populations (good on ya alan, most people don't consider that)... kai asked a variety of interesting questions, thouhg, which i tried to answer in his comments... like lonervamp mentions at the start of this post, discussions like this are something i'd prefer not to lose to the sands of time so i'm reposting my comments here (and i may start doing this more often, 'cause it seems like a great idea):
alan is right, of course, that anti-virus does a lot more than just catch viruses these days, and that anti-virus helps control older virus populations (good on ya alan, most people don't consider that)... kai asked a variety of interesting questions, thouhg, which i tried to answer in his comments... like lonervamp mentions at the start of this post, discussions like this are something i'd prefer not to lose to the sands of time so i'm reposting my comments here (and i may start doing this more often, 'cause it seems like a great idea):
"Have the virus authors started to write smaller virus that stays below the radar - and thus are not detected by the AV-products?"
many of the virus authors of old have simply grown up and found more fulfilling things to do with their lives...
"Are they now only targeting special targets - like particular banks, SCADA or singled out corporations? Or countries and causes? Or are they too busy writing malware to care about virus? "
viruses are malware... non-viral malware, however, seems to be what the cyber-crooks prefer these days... self-replication has a way of getting out of hand and calling attention to the malware...
"Do we really need to pay out on gateway and client AV solutions if there are no virus knocking on the door? "
who says there isn't? just because you aren't hearing about new epidemics doesn't mean new viruses aren't getting written or even that the old ones have stopped... some of the most prevalent email-born malware are mass-mailing worms that are already a few years old (like netsky.p)...
"Do you believe that there are no more virus out there?"
absolutely not... some people are still getting infected by decades-old boot infectors...
"That other threats are taking over and rendering AV-solutions useless?"
other threats are just as detectable with av as viruses are...
"Is this the whole truth? Or have the AV solutions became so good that they catch everything, even without us noticing? That they are an absolute critical part of the solution for any entity connected to the net?"
let's put it this way - old viruses never die, their populations just shrink to a size too small to accurately report/track... av is one of the things that helps keep those populations small...
and when it comes to newer non-viral malware, av is what helps keep it's usability limited... without the blacklist, the bad guys would just find something that successfully bypassed other defenses and keep using it over and over because other defenses cannot be updated as fast as a blacklist...
Tags:
alan shimel,
anti-virus,
kai roer,
lonervamp,
malware
Thursday, October 02, 2008
symantec's reputation is in the clouds
the folks at symantec posted something interesting today - It's All About Reputation...
well, they're not the first ones to go into the cloud (obviously, see panda, trend, mcafee, etc)... nor are they the first to go with a reputation system (drive sentry, for starters)... are they the first to put a reputation system in the cloud? i don't know, maybe, but at this point it still doesn't seem like such a big deal...
what gets me, though, is the idea that it's no longer using fingerprints... a reputation system that says X is good, Y is bad, and Z is unknown is basically just a combination of a blacklist and a whitelist - and it's not a bad idea, i've been saying they complement each other well for quite a while now so actually putting both paradigms into a single product makes a lot of sense... the blacklist is what says Y is bad, the whitelist is what says X is good, and since Z isn't on either list it gets called unknown... the thing is blacklists use signatures (fingerprints) and in their own way whitelists do to - they have to in order to make sure the thing you're looking at really is the same thing you saw before and determined to be good/bad... it can't work without a signature/fingerprint/whatever... this new reputation system may use a different form of signatures, but it definitely uses them...
and as for how this protects you from brand new threats as the post suggests, i can only imagine it works like this: things on the blacklist are stopped from executing automatically, things on the whitelist are allowed to execute transparently, and things that aren't on either list will cause the user to be given an "are you sure?" prompt... finally, someone's putting dr. solly's perfect.bat (which asked the user if the file being scanned was a virus or not) to good use...
the other way it might work is that the unknowns get automatically run in a sandbox of some sort... not a sandbox meant for malware classification, mind you (a number of products already do that), but a sandbox intended to separate the handling of untrusted items from the trusted host system... i mean, since they're already adding 2 of the 3 preventative paradigms into a single product (hopefully seamlessly), wouldn't it be cool if they added the 3rd as well? i won't hold my breath for them actually implementing this, though...
well, they're not the first ones to go into the cloud (obviously, see panda, trend, mcafee, etc)... nor are they the first to go with a reputation system (drive sentry, for starters)... are they the first to put a reputation system in the cloud? i don't know, maybe, but at this point it still doesn't seem like such a big deal...
what gets me, though, is the idea that it's no longer using fingerprints... a reputation system that says X is good, Y is bad, and Z is unknown is basically just a combination of a blacklist and a whitelist - and it's not a bad idea, i've been saying they complement each other well for quite a while now so actually putting both paradigms into a single product makes a lot of sense... the blacklist is what says Y is bad, the whitelist is what says X is good, and since Z isn't on either list it gets called unknown... the thing is blacklists use signatures (fingerprints) and in their own way whitelists do to - they have to in order to make sure the thing you're looking at really is the same thing you saw before and determined to be good/bad... it can't work without a signature/fingerprint/whatever... this new reputation system may use a different form of signatures, but it definitely uses them...
and as for how this protects you from brand new threats as the post suggests, i can only imagine it works like this: things on the blacklist are stopped from executing automatically, things on the whitelist are allowed to execute transparently, and things that aren't on either list will cause the user to be given an "are you sure?" prompt... finally, someone's putting dr. solly's perfect.bat (which asked the user if the file being scanned was a virus or not) to good use...
the other way it might work is that the unknowns get automatically run in a sandbox of some sort... not a sandbox meant for malware classification, mind you (a number of products already do that), but a sandbox intended to separate the handling of untrusted items from the trusted host system... i mean, since they're already adding 2 of the 3 preventative paradigms into a single product (hopefully seamlessly), wouldn't it be cool if they added the 3rd as well? i won't hold my breath for them actually implementing this, though...
suggested reading
- SecuriTeam Blogs » Worditudinality
rob slade on why technical jargon, unlike normal language, should not be considered 'living'... - The Security Catalyst » Catalyst Conversation Starter: The High Cost of “Freeware”
interesting observations by michael santarcangelo about the hidden costs of freeware security... i think the secret to keeping the cost low is to know the right programs to pick or the right people to ask, but his experience should give the vendors of the products he examined (and those like them) a reason to reevaluate what they've been doing... - ThreatBlog » Blog Archive » VirusTotal is not a Comparative Analysis Tool!
that's right, it's not... nor does it accurately represent the detection capabilities of the products it uses... but is that going to stop the naysayers from continuing to use it as 'proof' that av sucks? not as long as it continues to serve as a source of confirmation for their confirmation bias... - hype-free: Autorun malware
this has a good description of the autorun feature and a number of ways to disable it
Tags:
suggested reading
Saturday, September 27, 2008
from the 'what were they thinking?' file
using the (incredible?) hulk as an av spokesperson:

i actually saw a very small version of this in a print ad some time ago and i thought it was hilarious at the time but i couldn't find it anywhere online so that i could share it... graham just reminded me of it and better still pointed to a site where one might find it and low and behold here it is...
and why did i think it was hilarious? well, the hulk is certainly powerful, no one can deny that, but the hulk also has one major weakness - he's a dumbass... and that's who symantec chose to represent their product... well i guess it's better than a picture of peter norton who once famously said that computer viruses were an urban legend like alligators in the sewers of new york... yes, that's right, the same peter norton that norton anti-virus is named after...

i actually saw a very small version of this in a print ad some time ago and i thought it was hilarious at the time but i couldn't find it anywhere online so that i could share it... graham just reminded me of it and better still pointed to a site where one might find it and low and behold here it is...
and why did i think it was hilarious? well, the hulk is certainly powerful, no one can deny that, but the hulk also has one major weakness - he's a dumbass... and that's who symantec chose to represent their product... well i guess it's better than a picture of peter norton who once famously said that computer viruses were an urban legend like alligators in the sewers of new york... yes, that's right, the same peter norton that norton anti-virus is named after...
av product removal tools
i saw this article on ghacks.net about the McAfee Consumer Product Removal Tool and it reminded me of that xkcd cartoon that i wrote about not too long ago...
on the subject of doing your job horribly wrong, i think we can all agree that both symantec and mcafee are doing their job of providing quality anti-malware software horribly wrong when you consider they make removal tools to get rid of their own products...
it has to be considered an ignominious distinction when you have to do for your own anti-malware product what you've previously done for particularly nasty bits of malware - write dedicated removal tools and manual removal instructions...
worse still when those methods don't work... some of the IT guys at work not too long ago spent nearly a full day all told trying to remove an older version of symantec's product from my work machine (in order to put on the new symantec endpoint protection product) with no luck... the removal tools didn't help - the manual instructions might have if there'd been time left to try them on the first day... thankfully when our head of IT took a look at it on the second day, he had better luck...
on the subject of doing your job horribly wrong, i think we can all agree that both symantec and mcafee are doing their job of providing quality anti-malware software horribly wrong when you consider they make removal tools to get rid of their own products...
it has to be considered an ignominious distinction when you have to do for your own anti-malware product what you've previously done for particularly nasty bits of malware - write dedicated removal tools and manual removal instructions...
worse still when those methods don't work... some of the IT guys at work not too long ago spent nearly a full day all told trying to remove an older version of symantec's product from my work machine (in order to put on the new symantec endpoint protection product) with no luck... the removal tools didn't help - the manual instructions might have if there'd been time left to try them on the first day... thankfully when our head of IT took a look at it on the second day, he had better luck...
Tags:
mcafee,
removal tools,
symantec
Wednesday, September 03, 2008
chrome follow-up
i mentioned in the previous post that there was a big gapping hole in chrome's sandboxing in that it doesn't sandbox plugins and that i was unable to obviate this problem by running chrome in a 3rd party sandbox... thanks to user Franklin on the wilders security forums i was pointed towards this sandboxie support forum thread that suggests you can make chrome work in sandboxie if you allow sandboxed apps to load kernel drivers outside of the sandbox... sandboxie itself strongly recommends against doing so, as do a few of the participants in the thread... lowering the security of sandboxie in order to make chrome work sort of defeats the purpose of using sandboxie to shore up the gapping hole in chrome's sandboxing...
in addition to that problem, however, it seems that even after you uninstall chrome it leaves a scheduled task behind to run the googleupdate program and the googleupdate.exe itself is also left behind... i've seen data files left behind after an uninstall before but i don't think i've ever seen binaries left behind (or if i have it's rare enough that i don't recall it) - that's a pretty crappy uninstall...
in addition to that problem, however, it seems that even after you uninstall chrome it leaves a scheduled task behind to run the googleupdate program and the googleupdate.exe itself is also left behind... i've seen data files left behind after an uninstall before but i don't think i've ever seen binaries left behind (or if i have it's rare enough that i don't recall it) - that's a pretty crappy uninstall...
Tuesday, September 02, 2008
chrome plated security
seems like everyone is talking about google's new browser called chrome... google even made a comic book about the product...
the comic describes a lot of what went into chrome and it sounds like google made some very interesting design decisions, like making it a multi-process application instead of simply multi-threaded, or their new javascript engine... it also captures the google aesthetic quite well...
those aren't enough to make me switch browsers however... i enjoy a certain level of security with my current setup and would like at least an equivalent level from any alternative browser but it doesn't seem like i'd be able to get that from chrome...
chrome implements two of the three preventative paradigms i've written about before... specifically it implements blacklisting of sites (both sites known to host malware and sites known to be phishing pages) and it implements sandboxing... what it doesn't seem to implement (at least the comic made no mention of it and i saw no sign when i tested it out) is whitelisting...
there are a couple of reasons why whitelisting may have been left out of the mix... the most simplistic of which being they simply weren't familiar with the concept - indeed, website blacklists are in most modern browsers now so they're well known, and there was a mini boom of browser sandboxing tools (enough that google actually acquired one called greenborder last year) so they should be on google's radar too... as far as whitelisting active web content goes, however, there aren't a lot of players - noscript stands out as the only one i can think of (other than IE's trusted zone which almost no one uses because it's not user friendly)...
if we assume google was familiar with whitelisting active web content in general and noscript in particular then another possible reason for it's exclusion emerges - when you look at the frequency of noscript updates (updates that are more than just a new list as you'd get with a blacklist update, updates to the codebase itself) you come away with the impression that technology like noscript is far better off as a plugin than built into the browser... i don't think anyone wants to update their entire browser that often...
finally, a thought that formed while commenting on michael farnum's blog - there seems to be a fundamental philosophical conflict between the default-deny paradigm that whitelists represent and organic growth of application ecosystems... the way web content is developed can be considered to be the very embodiment of organic growth and google makes it pretty clear that they want to help that along, not get in it's way, so it could very well be that whitelisting simply doesn't fit in their security vision...
it's a rather important part of mine, however, so at the very least i won't be switching to chrome until someone makes a noscript-like plugin for it... things won't be all sunshine and lollipops when that happens, though... as i mentioned earlier, the browser is supposed to have sandboxing built in and on the surface that sounds great... unfortunately they haven't figured out how to sandbox plugins... this seems like a pretty big deal to me because flash is a plugin and shockwave is a plugin and quicktime is a plugin, etc... the very active content that isn't being controlled by way of a whitelist is apparently not being contained by their sandboxing technique either... this seems a little backwards because i'm fairly sure that back in the days when greenborder was still around if you ran your browser in that sandbox the plugins stayed in the sandbox too... no worries, we'll just run chrome inside another sandbox like sandboxie - right? try it and you too may be greeted with the "sad tab"...

i've no idea why (i'm no sandboxie power-user) but all pages lead to sad inside a second sandbox and the helpful reload advice sometimes leads to the frozen tab (and boy does he look cold)...
from the looks of things in process explorer, each tab process runs in a sandboxed process with the unsandboxed browser process as the parent but when the browser process is sandboxed it doesn't appear to be able to create it's own sandboxed children (even though a sandboxed firefox can launch vlc in the sandbox without trouble)...
so there's no whitelist and not only is the built in sandboxing insufficient, it appears to kill the option of using a 3rd party sandbox to make up for it's deficiencies... it's pretty, don't get me wrong, i like the look of it - i also like the idea of faster javascript, but i get more security with my current browser setup and when legitimate sites like yahoo mail or cnn are sometimes found to be serving malicious content that security becomes pretty important...
the comic describes a lot of what went into chrome and it sounds like google made some very interesting design decisions, like making it a multi-process application instead of simply multi-threaded, or their new javascript engine... it also captures the google aesthetic quite well...
those aren't enough to make me switch browsers however... i enjoy a certain level of security with my current setup and would like at least an equivalent level from any alternative browser but it doesn't seem like i'd be able to get that from chrome...
chrome implements two of the three preventative paradigms i've written about before... specifically it implements blacklisting of sites (both sites known to host malware and sites known to be phishing pages) and it implements sandboxing... what it doesn't seem to implement (at least the comic made no mention of it and i saw no sign when i tested it out) is whitelisting...
there are a couple of reasons why whitelisting may have been left out of the mix... the most simplistic of which being they simply weren't familiar with the concept - indeed, website blacklists are in most modern browsers now so they're well known, and there was a mini boom of browser sandboxing tools (enough that google actually acquired one called greenborder last year) so they should be on google's radar too... as far as whitelisting active web content goes, however, there aren't a lot of players - noscript stands out as the only one i can think of (other than IE's trusted zone which almost no one uses because it's not user friendly)...
if we assume google was familiar with whitelisting active web content in general and noscript in particular then another possible reason for it's exclusion emerges - when you look at the frequency of noscript updates (updates that are more than just a new list as you'd get with a blacklist update, updates to the codebase itself) you come away with the impression that technology like noscript is far better off as a plugin than built into the browser... i don't think anyone wants to update their entire browser that often...
finally, a thought that formed while commenting on michael farnum's blog - there seems to be a fundamental philosophical conflict between the default-deny paradigm that whitelists represent and organic growth of application ecosystems... the way web content is developed can be considered to be the very embodiment of organic growth and google makes it pretty clear that they want to help that along, not get in it's way, so it could very well be that whitelisting simply doesn't fit in their security vision...
it's a rather important part of mine, however, so at the very least i won't be switching to chrome until someone makes a noscript-like plugin for it... things won't be all sunshine and lollipops when that happens, though... as i mentioned earlier, the browser is supposed to have sandboxing built in and on the surface that sounds great... unfortunately they haven't figured out how to sandbox plugins... this seems like a pretty big deal to me because flash is a plugin and shockwave is a plugin and quicktime is a plugin, etc... the very active content that isn't being controlled by way of a whitelist is apparently not being contained by their sandboxing technique either... this seems a little backwards because i'm fairly sure that back in the days when greenborder was still around if you ran your browser in that sandbox the plugins stayed in the sandbox too... no worries, we'll just run chrome inside another sandbox like sandboxie - right? try it and you too may be greeted with the "sad tab"...
i've no idea why (i'm no sandboxie power-user) but all pages lead to sad inside a second sandbox and the helpful reload advice sometimes leads to the frozen tab (and boy does he look cold)...
from the looks of things in process explorer, each tab process runs in a sandboxed process with the unsandboxed browser process as the parent but when the browser process is sandboxed it doesn't appear to be able to create it's own sandboxed children (even though a sandboxed firefox can launch vlc in the sandbox without trouble)...
so there's no whitelist and not only is the built in sandboxing insufficient, it appears to kill the option of using a 3rd party sandbox to make up for it's deficiencies... it's pretty, don't get me wrong, i like the look of it - i also like the idea of faster javascript, but i get more security with my current browser setup and when legitimate sites like yahoo mail or cnn are sometimes found to be serving malicious content that security becomes pretty important...
Monday, September 01, 2008
what are anti-virus best practices?
i'll be blunt - some of this (maybe even all of it) is going to seem dead obvious... i'm sorry if this is old news you, however it would appear that quite a number of otherwise smart people (be they security professionals or [ahem] rocket scientists) have decided either that av marketing is gospel and thus been bitten by the ensuing false sense of security, or that av marketing should be trustworthy (even though the marketing for virtually every other product on the planet isn't) and became bitter and jaded because av failed to live up to the expectations that the marketing created...
just to be clear, this is going to be best practices for known-malware scanning (what most people consider to be the entirety of av)...
now, hopefully, most or all those smart people who i know are familiar with the concept of best practices will modify their expectations and stop listening to those marketing departments that are filling their heads with lies... (stop. listening. to marketing!)
just to be clear, this is going to be best practices for known-malware scanning (what most people consider to be the entirety of av)...
- use it - i don't just mean have it installed, i mean sit down and actually scan things (like files you download or removable media you insert into your computer) from time to time (and scanning the entire drive on an automated schedule doesn't count)... install and forget security is bullshit... you need to interact with the software, to learn what it's alerts actually look like so you can distinguish them from fake alerts, and to become skilled in the actual use of the tool...
some may say that's working for your security software instead of making it work for you and real people have real jobs to do, but it doesn't actually take much time or effort to scan incoming materials and both of those other concepts ('working for the software' and 'making it work for you') are nonsense... it's a tool, and like any tool you can only get out of it what you put into it... if you don't know how to use it properly then you ultimately won't do as good a job at protecting yourself with it as you might have otherwise... it's a poor craftsman who blames his tools... - keep it up to date - known-malware scanners are only as good as the knowledge-base they embody... new malware is being created at a rather incredible rate and the only way to make known-malware scanners effective against that new malware is to update those scanners with 'knowledge' of that new malware...
sure there are other types of anti-malware software that don't require such updates, but they also don't come with expert knowledge about known-malware built into them and so are of little diagnostic value when prevention inevitably fails... also, it's always easiest to prevent something bad if you 'know' specifically what to look for... - quarantine first - don't trust the scanner to automatically delete things it thinks are bad... scanners make mistakes and you don't want to compound those mistakes by allowing the scanner to automagically delete critical files...
trust the results enough to consider that the file(s) in question may be bad, but verify those results, and verify that it's safe to get rid of the file(s) before you actually do so... trust but verify... - don't rely on it alone - just as you shouldn't place absolute trust in it's results when it detects something you also shouldn't place absolute trust in it when it doesn't find anything... this is probably the best practice most directly in conflict with av marketing, and there are a number of people i really wish would stop listening to marketing and catch up because i learned of the benefits of using a multi-layered approach (what would be better known now as defense in depth) back in the early 90's thanks to the people who actually made (rather than marketed) this stuff...
you need to use other types of anti-malware technology in conjunction with scanners (not just additional scanners) if for no other reason than because there will always be a window of time between when a new piece of malware is created and when an update for that malware is made available... in other words: if the malware's too new, a scanner won't do... - scan from a known-clean environment - just as you shouldn't necessarily trust the scanner you also shouldn't trust an infected or even possibly infected machine... this likely won't seem intuitive since the av industry itself has for years been producing features and services that contradict this such as web based scanners or the ubiquitous scheduled system scan... in an effort to be less of an uncompromising s.o.b. let me say that those are features and services that are offered for convenience and shouldn't be solely relied upon as they do not replace outside-the-box scanning...
you can't trust a compromised environment to accurately report it's own integrity... the code the runs first wins and the only way to make sure malware doesn't run first is to operate in an environment where no code from the suspect system has run; not the operating system, not even the boot sectors...
now, hopefully, most or all those smart people who i know are familiar with the concept of best practices will modify their expectations and stop listening to those marketing departments that are filling their heads with lies... (stop. listening. to marketing!)
Sunday, August 31, 2008
suggested reading
- Don't be naive: computers will never be secure | Phil Hendren - Times Online
a great article about the impossibility of total security, the inevitability of security weaknesses, and the responsibility of individual users to take care of their own security... - The Art Of Noh: The dark side of teaching
another look at teaching malware writing in schools, this time from someone once faced with such a curriculum... - Sampling a Malicious Site « Didier Stevens
a nice little video showing the extraction of malware from a malicious site... - TaoSecurity: Microsecurity vs Macrosecurity
an interesting delineation between two security approaches... - Spire Security Viewpoint: Response to Schneier on Full Disclosure
some interesting thoughts on vulnerability disclosure (and indeed, vulnerability research itself) that don't often get heard above the din produced by the full-disclosure-or-bust crowd... - Removing Malware With a Live CD « Didier Stevens
i highlighted the f-secure livecd when they wrote about it on their blog so it's only natural that i'd also highlight a video demonstrating it's use as well... - An Unexpected Demonstration of Mobile Security - F-Secure Weblog : News from the Lab
an intersection between the concepts of mobile malware and old malware, showing that even in the mobile market old platforms (and thus old malware) can still be found and still cause (some) problems... - AMTSO Blog » Blog Archive » Principles and Guidelines available for download
a good read if you're at all interested in how anti-malware products *should* be tested... i like that the very first principle is to not endanger the public - it's very reminiscent of "above all else, do no harm"... it's a principle that's fairly well established in the mainstream anti-malware community but seems to be noticeably absent elsewhere... - ThreatBlog » Blog Archive » It Doesn’t Hurt to Ask
this isn't the first time randy has underlined an easily exploited weakness in a social engineering scheme, and hopefully it won't be the last... "ask now, click later" indeed...
Tags:
suggested reading
viruses on the international space station
this past week there was a lot of buzz surrounding the news that an autorun worm had infected 2 laptops aboard the international space station... i wasn't sure i was going to bother saying anything about it at first but then i decided it might serve as an interesting object lesson so let's look at what we can learn from this event and what could have been done differently....
my first reaction when reading of the event was that this just goes to show how pernicious and autonomous self-replicating malware truly is... that notion (that viruses/worms are somehow worse or more autonomous than other forms of malware) has been scoffed at in the past but viruses in space stand as a testament to their ability to get into places no one intended or would have imagined... no other form of malware besides self-replicators would have been able to find new victims in that sort of environment...
another thing we can learn from this is to stop clinging to the fantasy that the only kind of malware we need to worry about anymore is the new stuff, that old-style viruses and worms aren't worth worrying about anymore... this wasn't brand new malware, it wasn't state of the art, and it wasn't something researchers on the bleeding edge would have taken notice of even when it was new... the malware threat landscape isn't composed exclusively of novelties, there's a heck of a lot of banality out there as well...
yet another lesson is that can be learned is that for all the whining about how AV is failing, at least some of the evidence used to support that argument (in other words, some of the failures) is actually a result of not using AV in the first place, not keeping it up to date, or not following the various other best practices for AV...
actually using an AV program is the first thing the astronauts and/or NASA could have done differently... while i'm sure there are plenty of arguments for why one might not want an anti-virus program on them, such as highly critical real-time processing of experimental data, these were laptops running windows and so were already unsuitable for real-time processing ('what do you mean the OS must have been busy don't something else during that time period?')... i assume someone up there must have had AV or else we wouldn't have a name for the malware...
failing that, they could have used some other sort of anti-malware technology like application whitelisting... in fact, considering the environment that might even be a more appropriate approach since it's unlikely that astronauts need to introduce new software to those machines very often... that is unless part of their job requires them to rewrite or apply patches to software being used in the experiments to collect/analyze data... come to think of it, that might actually be the case - it's not like the folks designing the experimental payloads have a lot of chances to test and debug their software under real-world conditions when the real-world in question is actually out of this world...
the astronauts could have operated the machines under non-administrative accounts - actually there isn't really anything to suggest they didn't, nor is there anything specific to an autorun worm's replication technique that should require administrative access... despite a previous post i made highlighting the ways in which least privilege can fail to stop malware, it still is fairly effective against a lot of existing malware...
they could have disabled autorun on those machines - in fact, they probably still should disable it... autorun is purely a convenience feature for the technologically inept; hopefully that's not the sort of folks NASA is sending into space (then again, they did get infected by somewhat old malware)...
finally, they could have used something other than windows machines... although technically not immune to malware, macs and linux machines have a far smaller pool of threat agents to worry about and the lower population density means that they are less connected to other similar endpoints that could pass on something they'd be susceptible to... of course, once again this is likely subject to what the machines are being used for - if they're running or monitoring experiments with them then they may be stuck with whatever the people who designed those experiments wrote their software for (and considering the cost of doing anything in space, cutting corners on the ground and using cheap windows developers is pretty likely)...
according to NASA this is not the first time they've had a virus infection in space... let's hope they also look at these sorts of events as learning experiences and figure out how to do things better in future...
my first reaction when reading of the event was that this just goes to show how pernicious and autonomous self-replicating malware truly is... that notion (that viruses/worms are somehow worse or more autonomous than other forms of malware) has been scoffed at in the past but viruses in space stand as a testament to their ability to get into places no one intended or would have imagined... no other form of malware besides self-replicators would have been able to find new victims in that sort of environment...
another thing we can learn from this is to stop clinging to the fantasy that the only kind of malware we need to worry about anymore is the new stuff, that old-style viruses and worms aren't worth worrying about anymore... this wasn't brand new malware, it wasn't state of the art, and it wasn't something researchers on the bleeding edge would have taken notice of even when it was new... the malware threat landscape isn't composed exclusively of novelties, there's a heck of a lot of banality out there as well...
yet another lesson is that can be learned is that for all the whining about how AV is failing, at least some of the evidence used to support that argument (in other words, some of the failures) is actually a result of not using AV in the first place, not keeping it up to date, or not following the various other best practices for AV...
actually using an AV program is the first thing the astronauts and/or NASA could have done differently... while i'm sure there are plenty of arguments for why one might not want an anti-virus program on them, such as highly critical real-time processing of experimental data, these were laptops running windows and so were already unsuitable for real-time processing ('what do you mean the OS must have been busy don't something else during that time period?')... i assume someone up there must have had AV or else we wouldn't have a name for the malware...
failing that, they could have used some other sort of anti-malware technology like application whitelisting... in fact, considering the environment that might even be a more appropriate approach since it's unlikely that astronauts need to introduce new software to those machines very often... that is unless part of their job requires them to rewrite or apply patches to software being used in the experiments to collect/analyze data... come to think of it, that might actually be the case - it's not like the folks designing the experimental payloads have a lot of chances to test and debug their software under real-world conditions when the real-world in question is actually out of this world...
the astronauts could have operated the machines under non-administrative accounts - actually there isn't really anything to suggest they didn't, nor is there anything specific to an autorun worm's replication technique that should require administrative access... despite a previous post i made highlighting the ways in which least privilege can fail to stop malware, it still is fairly effective against a lot of existing malware...
they could have disabled autorun on those machines - in fact, they probably still should disable it... autorun is purely a convenience feature for the technologically inept; hopefully that's not the sort of folks NASA is sending into space (then again, they did get infected by somewhat old malware)...
finally, they could have used something other than windows machines... although technically not immune to malware, macs and linux machines have a far smaller pool of threat agents to worry about and the lower population density means that they are less connected to other similar endpoints that could pass on something they'd be susceptible to... of course, once again this is likely subject to what the machines are being used for - if they're running or monitoring experiments with them then they may be stuck with whatever the people who designed those experiments wrote their software for (and considering the cost of doing anything in space, cutting corners on the ground and using cheap windows developers is pretty likely)...
according to NASA this is not the first time they've had a virus infection in space... let's hope they also look at these sorts of events as learning experiences and figure out how to do things better in future...
Tags:
autorun worm,
international space station,
malware,
virus,
worm
what is an autorun worm?
an autorun worm is a type of worm that is carried (literally) from one machine to another on removable media (such as CDs, DVDs, or USB flash drives) and uses the autorun feature of windows to either automate or at the very least facilitate it's execution when the media is put into the next computer...
this type of worm makes use of the autorun facility by copying not only itself to removable media but also placing an autorun.inf file on the media that contains the instructions necessary to run the worm's program when the media is inserted into a machine that has the autorun facility enabled...
although the autorun facility works by default for CDs and DVDs (as you've no doubt noticed when inserting some of them into your computer), it doesn't work by default for standard USB flash drives - something called autoplay (which shows the user a menu of convenient actions s/he can take such as playing audio/video, opening the drive in explorer, etc) is initiated instead...
that said, there are changes one can make to a computer to make it initiate autorun instead of autoplay, there are specially designed USB flash drives that lie to windows about what kind of device they are in order to make use of autorun, and other USB devices can't reasonably be expected to identify themselves as standard USB flash drives when that's not what they are and so pose the potential of initiating autorun when used... also, even if autorun doesn't automatically initiate as soon as the media is inserted into the computer, it may initiate when you double-click on the drive in explorer... additionally, for contexts where autoplay is initiated, the autorun.inf file can specify actions (such as executing the worm) to be added to the top of the menu that the user is presented with and which can be presented in a deceptive manner so as to trick the user into choosing the malicious action added by autorun.inf file...
back to index
this type of worm makes use of the autorun facility by copying not only itself to removable media but also placing an autorun.inf file on the media that contains the instructions necessary to run the worm's program when the media is inserted into a machine that has the autorun facility enabled...
although the autorun facility works by default for CDs and DVDs (as you've no doubt noticed when inserting some of them into your computer), it doesn't work by default for standard USB flash drives - something called autoplay (which shows the user a menu of convenient actions s/he can take such as playing audio/video, opening the drive in explorer, etc) is initiated instead...
that said, there are changes one can make to a computer to make it initiate autorun instead of autoplay, there are specially designed USB flash drives that lie to windows about what kind of device they are in order to make use of autorun, and other USB devices can't reasonably be expected to identify themselves as standard USB flash drives when that's not what they are and so pose the potential of initiating autorun when used... also, even if autorun doesn't automatically initiate as soon as the media is inserted into the computer, it may initiate when you double-click on the drive in explorer... additionally, for contexts where autoplay is initiated, the autorun.inf file can specify actions (such as executing the worm) to be added to the top of the menu that the user is presented with and which can be presented in a deceptive manner so as to trick the user into choosing the malicious action added by autorun.inf file...
back to index
Tags:
autorun worm,
definition,
worm
Tuesday, August 26, 2008
can facebook sanitize application content?
while reading through some blogs this evening i happened across this article by ryan naraine pointing to a register article by dan goodin about an apparent security vulnerability in facebook's 3rd party application platform that allows arbitrary (and possibly malicious) javascript to be executed...
what struck my eye was a notion that facebook was failing to sanitize application content...
this struck me as an odd statement... i've heard of sanitizing input/data - that's something that makes sense since data should adhere to a strictly defined format... names don't go where dates should be, numbers should actually be numeric, escape sequences should be filtered, etc... it's possible to reject everything that doesn't meet the pre-defined criteria...
i'm going to put on my computer scientist hat and say the same is not applicable to applications written in a turing complete language (which javascript is)... the only way to truly 'sanitize' them is to come up with an entirely new and decidedly less than turing complete language for people to use instead... that is likely outside the scope of what facebook or any other application platform provider is willing to invest their time in - especially since it creates a far more restrictive and less rewarding environment for 3rd party application developers to work with, leading to the very likely result of driving them to other, less restrictive platforms...
that's not to say there aren't some specific instruction sequences that facebook can try to filter out, however with all the ways to obfuscate javascript i doubt it would accomplish much - and even if obfuscation weren't a problem the turing completeness would be; you'd never be able to list (never mind filter) all the possible malicious sequences of instructions, nor could you definitively say that those instructions would ever actually be interpreted by the javascript interpreter of a visitor's browser... detecting malicious sequences of javascript instructions in 3rd party applications is similar to detecting malicious programs like viruses or worms - in fact, they are identical problems and so it should come as no surprise that detecting such malicious sequences of javascript instructions (a necessary precursor to sanitizing the javascript) is reducible to the halting problem... therefore facebook may technically be correct in saying there's no vulnerability (though i have no idea if they actually analyzed the issue in this manner) in the sense that most people would consider... just because you can do bad things doesn't mean there's a vulnerability... sometimes it just means there's more flexibility than you were expecting or wanted...
at any rate, facebook has other ways of dealing with malicious application content - they block the entire application once they discover it's bad... after all, even if they did somehow manage to sanitize javascript, what about flash? or java? or activex? it's not feasible to manually audit all applications before they're allowed to go live on facebook, and it's not possible to find all the malicious code with automated auditing because of the halting problem - so, like more traditional forms of malicious code, malicious facebook applications are something that must inevitably be dealt with after the fact...
what struck my eye was a notion that facebook was failing to sanitize application content...
this struck me as an odd statement... i've heard of sanitizing input/data - that's something that makes sense since data should adhere to a strictly defined format... names don't go where dates should be, numbers should actually be numeric, escape sequences should be filtered, etc... it's possible to reject everything that doesn't meet the pre-defined criteria...
i'm going to put on my computer scientist hat and say the same is not applicable to applications written in a turing complete language (which javascript is)... the only way to truly 'sanitize' them is to come up with an entirely new and decidedly less than turing complete language for people to use instead... that is likely outside the scope of what facebook or any other application platform provider is willing to invest their time in - especially since it creates a far more restrictive and less rewarding environment for 3rd party application developers to work with, leading to the very likely result of driving them to other, less restrictive platforms...
that's not to say there aren't some specific instruction sequences that facebook can try to filter out, however with all the ways to obfuscate javascript i doubt it would accomplish much - and even if obfuscation weren't a problem the turing completeness would be; you'd never be able to list (never mind filter) all the possible malicious sequences of instructions, nor could you definitively say that those instructions would ever actually be interpreted by the javascript interpreter of a visitor's browser... detecting malicious sequences of javascript instructions in 3rd party applications is similar to detecting malicious programs like viruses or worms - in fact, they are identical problems and so it should come as no surprise that detecting such malicious sequences of javascript instructions (a necessary precursor to sanitizing the javascript) is reducible to the halting problem... therefore facebook may technically be correct in saying there's no vulnerability (though i have no idea if they actually analyzed the issue in this manner) in the sense that most people would consider... just because you can do bad things doesn't mean there's a vulnerability... sometimes it just means there's more flexibility than you were expecting or wanted...
at any rate, facebook has other ways of dealing with malicious application content - they block the entire application once they discover it's bad... after all, even if they did somehow manage to sanitize javascript, what about flash? or java? or activex? it's not feasible to manually audit all applications before they're allowed to go live on facebook, and it's not possible to find all the malicious code with automated auditing because of the halting problem - so, like more traditional forms of malicious code, malicious facebook applications are something that must inevitably be dealt with after the fact...
Tags:
dan goodin,
facebook,
malware,
ryan naraine
Monday, August 18, 2008
xkcd, diebold voting machines, and anti-virus
i think by now just about everyone has seen this xkcd comic:

lots of people have posted their thoughts about it but unfortunately quite a number just don't get what it's about and missed the point by a wide margin...
the comic, titled "voting machines" (not "anti-virus") is about voting machines (not anti-virus)... imagine that... the artist compares av to condoms as an entirely acceptable preventative measure under ordinary circumstance but then points out that there are some circumstances where it's presence indicates something else has gone horribly wrong... that is the voting machine itself - there's no reason (other than diebold/premier election solutions being cheap and lazy) for a voting machine to be capable of running viruses, let alone anti-virus software, or even windows for that matter...
voting machines need to do one very narrowly defined thing, and they have to be incredibly reliable and resistant to tampering (after all, the future of your government depends on them)... those design criteria call for a special purpose (rather than general purpose) computer... computers that are physically incapable of doing anything more than carrying out the very narrowly defined set of tasks they were designed for... you've seen them before - cheap pocket calculators (as opposed to the fancy scientific ones), wrist watches, etc... putting extra power needlessly into the voting machines made them less reliable and less secure but it's cheaper to use off-the-shelf components and it's cheaper to pay for developers who work on general purpose platforms than those who work in embedded systems...
as the old saying goes: cheap, fast, good - pick 2...
(oh, and i should thank the comic's author, randall munroe, since, for a brief period anyways, guess who was the top result for searches on 'diebold antivirus')

lots of people have posted their thoughts about it but unfortunately quite a number just don't get what it's about and missed the point by a wide margin...
the comic, titled "voting machines" (not "anti-virus") is about voting machines (not anti-virus)... imagine that... the artist compares av to condoms as an entirely acceptable preventative measure under ordinary circumstance but then points out that there are some circumstances where it's presence indicates something else has gone horribly wrong... that is the voting machine itself - there's no reason (other than diebold/premier election solutions being cheap and lazy) for a voting machine to be capable of running viruses, let alone anti-virus software, or even windows for that matter...
voting machines need to do one very narrowly defined thing, and they have to be incredibly reliable and resistant to tampering (after all, the future of your government depends on them)... those design criteria call for a special purpose (rather than general purpose) computer... computers that are physically incapable of doing anything more than carrying out the very narrowly defined set of tasks they were designed for... you've seen them before - cheap pocket calculators (as opposed to the fancy scientific ones), wrist watches, etc... putting extra power needlessly into the voting machines made them less reliable and less secure but it's cheaper to use off-the-shelf components and it's cheaper to pay for developers who work on general purpose platforms than those who work in embedded systems...
as the old saying goes: cheap, fast, good - pick 2...
(oh, and i should thank the comic's author, randall munroe, since, for a brief period anyways, guess who was the top result for searches on 'diebold antivirus')
Sunday, August 17, 2008
terminology rant
remember me saying the word infect (and it's derivatives) was overused/misused? probably you don't, this blog had a lot fewer readers back then...
but infect is still being overused and here's an example... describing the deployment of a drive-by download attack as putting up an infected website... viruses are what infect things but viruses only infect programs (or computers in the case of the subset known as worms)... websites aren't programs (though they may contain one or more of them in the form of scripts/flash/etc) and what gets put on them for drive-by downloads are generally not viruses but rather some non-viral form of malware...
misusing the term 'infect' like this reminds us that collectively we still haven't gotten over calling all malware a virus, and i think by now we've all realized that such imprecise thinking/communicating only leads to ambiguity and confusion...
so, like i did when i suggested an alternate term for when a computer has non-viral malware, i'm going to suggest a term (2 actually) for the websites used in drive-by downloads... the first should be rather obvious, when the entire website itself is put up by the blackhat then it's a malicious site - no need to mince words, the site attacks visitors in one way or another so it's malicious... the other comes about because sometimes the malicious content is on what is otherwise a completely legitimate site like yahoo or cnn or the superbowl... we can't exactly call those malicious sites, however we can call them tainted sites (maybe even poisoned sites for those who prefer more pejorative terms)...
but infect is still being overused and here's an example... describing the deployment of a drive-by download attack as putting up an infected website... viruses are what infect things but viruses only infect programs (or computers in the case of the subset known as worms)... websites aren't programs (though they may contain one or more of them in the form of scripts/flash/etc) and what gets put on them for drive-by downloads are generally not viruses but rather some non-viral form of malware...
misusing the term 'infect' like this reminds us that collectively we still haven't gotten over calling all malware a virus, and i think by now we've all realized that such imprecise thinking/communicating only leads to ambiguity and confusion...
so, like i did when i suggested an alternate term for when a computer has non-viral malware, i'm going to suggest a term (2 actually) for the websites used in drive-by downloads... the first should be rather obvious, when the entire website itself is put up by the blackhat then it's a malicious site - no need to mince words, the site attacks visitors in one way or another so it's malicious... the other comes about because sometimes the malicious content is on what is otherwise a completely legitimate site like yahoo or cnn or the superbowl... we can't exactly call those malicious sites, however we can call them tainted sites (maybe even poisoned sites for those who prefer more pejorative terms)...
Tags:
drive-by download,
malware,
poison,
terminology misuse
china, disclosure, and malware
not too long ago, amrit williams wrote on his experience traveling in south-east asia and specifically his observation of their attitudes towards malware disclosure:
i suppose perhaps if you were only looking at the technological side of the malware problem the easy availability of malware for study should theoretically be of help... but i have to wonder: when most of the population is not involved in the creation of tools to help defend against malware, and when those that are involved have fairly open access to malware even over here in the west, what advantage is china's undifferentiated openness really giving them in practice?...
if we don't just look at the technological side, however, if we include the social component as well (especially as it relates to malware creation) then that openness comes under a different light... what do we know about china and malware in broad terms? well, although finjan's figures suggest china is not the biggest host of malware, according to kaspersky they are the largest producer of malware...
sharing malware materials helps learning about malware, there's no doubt about that, but uncontrolled/undifferentiated sharing (as opposed to the more reserved 'only if i know and trust you' type of sharing) helps the creation of malware more than it does the defense against malware, and china may well be serving as an unrecognized object lesson in that fact... so the next time we look at how other cultures handle issues differently, before concluding that they're doing things better because they're adhering more closely to abstract principles that we value, lets make sure we look at the larger picture and not lose the forest amongst the trees...
What I was shown was the most active and open distribution of malware, kits, and exploits I have ever witnessed. I will refrain from the details but considering the perceived insular nature of China and the openness of the US, I can tell you from the sharing of knowledge perspective we are way behind.though it's not completely unambiguous, i get the distinct impression (especially from wording of the statement that we're way behind) that he thinks we should be more like them... but i have to wonder what all that openness with regards to malware disclosure has actually done for china... are they better off than we are? are they better equipped to keep the malware problem in check?
I asked some questions about disclosure and was met with puzzled looks and shaking heads.
i suppose perhaps if you were only looking at the technological side of the malware problem the easy availability of malware for study should theoretically be of help... but i have to wonder: when most of the population is not involved in the creation of tools to help defend against malware, and when those that are involved have fairly open access to malware even over here in the west, what advantage is china's undifferentiated openness really giving them in practice?...
if we don't just look at the technological side, however, if we include the social component as well (especially as it relates to malware creation) then that openness comes under a different light... what do we know about china and malware in broad terms? well, although finjan's figures suggest china is not the biggest host of malware, according to kaspersky they are the largest producer of malware...
sharing malware materials helps learning about malware, there's no doubt about that, but uncontrolled/undifferentiated sharing (as opposed to the more reserved 'only if i know and trust you' type of sharing) helps the creation of malware more than it does the defense against malware, and china may well be serving as an unrecognized object lesson in that fact... so the next time we look at how other cultures handle issues differently, before concluding that they're doing things better because they're adhering more closely to abstract principles that we value, lets make sure we look at the larger picture and not lose the forest amongst the trees...
Tags:
amrit williams,
china,
disclosure,
malware,
malware creation
look who's drinking the whitelist koolaid now
from a recent blackhat-related post on symantec's blog:
the inflection point (shouldn't that really be an intersection of two curves?) will not and can not be reached... symantec is ignoring the figures provided by bit9 whose core business is application whitelists (so when they say good software is growing at a rate that is greater than what anyone says malware is growing at, despite the fact that it's in their interests to suggest the opposite, you better believe they know what the heck they're talking about)...
symantec is also ignoring the kind of basic logic i used 2 years ago when i said (without the benefit of figures) that good software outnumbers malware and grows faster than malware, and that i described in detail more recently: basically that malware writers are a small subset of the set of all programmers and there's no realistic way for a small group to outproduce a large group...
this reminds me of an earlier symantec gaffe wherein john thompson claimed the virus problem was solved... sometimes i wonder if symantec works on the philosophy of not letting the facts get in the way of good marketing...
Symantec has been stressing for quite some time that we are on the cusp of a critical inflection point where the number of unique malicious code instances is surpassing the number of legitimate code instances.
the inflection point (shouldn't that really be an intersection of two curves?) will not and can not be reached... symantec is ignoring the figures provided by bit9 whose core business is application whitelists (so when they say good software is growing at a rate that is greater than what anyone says malware is growing at, despite the fact that it's in their interests to suggest the opposite, you better believe they know what the heck they're talking about)...
symantec is also ignoring the kind of basic logic i used 2 years ago when i said (without the benefit of figures) that good software outnumbers malware and grows faster than malware, and that i described in detail more recently: basically that malware writers are a small subset of the set of all programmers and there's no realistic way for a small group to outproduce a large group...
this reminds me of an earlier symantec gaffe wherein john thompson claimed the virus problem was solved... sometimes i wonder if symantec works on the philosophy of not letting the facts get in the way of good marketing...
Saturday, August 09, 2008
is sympatico training their users to be victims?
sympatico, for those of you who don't know, is one of the largest (maybe the largest) ISPs in canada, owned and operated by bell canada (virtually our sole major telecom up here in the great white north)... i happen to be a sympatico subscriber, as i imagine many canadians are, so obviously i get to see all the various emails they send out... most of it is junk, complete rubbish that i have no interest in receiving telling me about products/services they're offering that i have no interest in using let alone paying for... unfortunately i can't very well block email from my ISP because someday far in the future they may possibly send me an email that's actually important... i don't think it's happened yet, but i can't rule out the possibility that it might happen in the future so i'm stuck weeding through mandatory spam...
i've been a sympatico subscriber for many years now, however, so this really isn't news... i've become largely numb to their marketing messages but there was one this past week that set off all sorts of alarms - it promises to enter the user into a draw for various valuable prizes if they'll download and run some executable that's described as internet check-up software... it's like something out of a malware spreader's social engineering playbook... even thunderbird thought it was a scam...

the completely wild thing is that all links point to sympatico/bell, it appears to be a genuine (if ill conceived) offer... i thought for sure the email was only pretending to be from sympatico, that while many of it's URLs might point to actual sympatico content there would still be one key url pointing to malicious content, but i was wrong... even the link to the software itself is theirs...
it seems to me that this highlights a need for adaptation from a group you normally wouldn't think would be particularly impacted by security threats: marketing departments... they need to change the way they market wares in order for their marketing message to not appear nefarious, but at the same time the black hats are going to continue to adopt any new marketing styles that marketing professionals come up with in order for their social engineering to appear legitimate... it's a strange concept to imagine that marketing needs to stay one step ahead of the bad guys, but at the end of the day i suspect that security threats (of all things) are going to change the face of marketing on the internet...
(and no, i'm not going to install the checkup software even though it appears to be legit - the whole thing just creeps me out too much)
i've been a sympatico subscriber for many years now, however, so this really isn't news... i've become largely numb to their marketing messages but there was one this past week that set off all sorts of alarms - it promises to enter the user into a draw for various valuable prizes if they'll download and run some executable that's described as internet check-up software... it's like something out of a malware spreader's social engineering playbook... even thunderbird thought it was a scam...
the completely wild thing is that all links point to sympatico/bell, it appears to be a genuine (if ill conceived) offer... i thought for sure the email was only pretending to be from sympatico, that while many of it's URLs might point to actual sympatico content there would still be one key url pointing to malicious content, but i was wrong... even the link to the software itself is theirs...
it seems to me that this highlights a need for adaptation from a group you normally wouldn't think would be particularly impacted by security threats: marketing departments... they need to change the way they market wares in order for their marketing message to not appear nefarious, but at the same time the black hats are going to continue to adopt any new marketing styles that marketing professionals come up with in order for their social engineering to appear legitimate... it's a strange concept to imagine that marketing needs to stay one step ahead of the bad guys, but at the end of the day i suspect that security threats (of all things) are going to change the face of marketing on the internet...
(and no, i'm not going to install the checkup software even though it appears to be legit - the whole thing just creeps me out too much)
Tags:
bell canada,
malware,
social engineering,
sympatico
on locks and keys
perhaps you've come across this story elsewhere, but boing boing has a piece on security researchers supposedly cracking the security of some physical lock system by making duplicate keys based on photos of the original...
is it just me or does that seem like a non-issue? what key-based lock isn't susceptible to replica keys? isn't that pretty much the nature of any token-based security system that if you can produce a duplicate token you're in? and aren't keys basically archaic tokens?
to me it seems that such research borders on captain obvious' territory, but here's a suggestion for lock-makers to help avoid this specific form of attack - retractable keys (hey, if they can do it for USB flash drives they ought to be able to do it for keys too) that you only extend directly into the lock mechanism... that way, in practice, the key portion should never need to be visible and thus wouldn't be susceptible to photographic acquisition...
is it just me or does that seem like a non-issue? what key-based lock isn't susceptible to replica keys? isn't that pretty much the nature of any token-based security system that if you can produce a duplicate token you're in? and aren't keys basically archaic tokens?
to me it seems that such research borders on captain obvious' territory, but here's a suggestion for lock-makers to help avoid this specific form of attack - retractable keys (hey, if they can do it for USB flash drives they ought to be able to do it for keys too) that you only extend directly into the lock mechanism... that way, in practice, the key portion should never need to be visible and thus wouldn't be susceptible to photographic acquisition...
Tags:
security
Friday, August 01, 2008
suggested reading
oops, a little on the late side, but not by too much...
- Chris Quirke's Blog: Should You Detect Old Malware?
another perspective on old malware - F-Secure Rescue CD 3.00 - F-Secure Weblog
tools like this need to get more attention - outside the box analysis is the best way to deal with stealth and other malware defense mechanisms... - Devil's Advocate Security - Malware Analysis and Response: A Quick Howto
i dunno why, i just like to see more approachable examples of malware incident response like this... i could almost see more or less ordinary people learning a thing or two from this, unlike those policy document driven enterprise level procedures... - Infectious Music, Malware-Style | TrendLabs | Malware Blog
interesting - i'm not sure if i'd call it infection but the fact that the music still plays after the 'codec' is downloaded is a neat twist... - Vulnerabilities in AV software - McAfee Avert Labs Blog
looks like i'm not the only one who saw fud in that '800 vulnerabilities in av software' report... this entry doesn't take as hard a line as i did, but there was a much more indepth analysis... - security religions (terminal23)
this is actually an older post but i've been wanting to comment on how good it is because after reading it i'm finding a lot of things i see falling into one of the two 'security religions' described here... now if only it didn't make me want to let things slide when folks are seriously wrong/misguided... - The End of Exponential Malware Growth? - McAfee Avert Labs Blog
this is perhaps one of the best pieces of news i've heard in a long, long time... i'll take it with a grain of salt because it almost seems too good to be true but there seems to be indications that malware growth has plateaued... i hope that continues... - Matasano Chargen » Internationalization of Malware
finally an explanation of why internationalization of malware matters - and that is the contextual information found in the strings in the binary... i'm still a proponent of entirely functional definitions/classification, but at least now i know why other people are concerned with this issue...
Tags:
suggested reading
Sunday, July 27, 2008
why anti-av is absurd
in point of fact, both anti-av and pro-av are absurd... i'll explain why in a moment...
given my comments about dancho danchev's anti-av leanings in my previous post, i anticipate there will be a number of people thinking (though not necessarily bothering to say it to my face) that i'm the polar opposite - fanatically pro-av... indeed, this has already happened in the past as there are those who wonder about my sanity, consider me an av extremist, and think i belong on the list of the 6 dumbest people in IT security (an homage to ranum's largely ill-conceived 6 dumbest ideas in IT security)...
let me ask you something, though... does it make sense to be pro-hammer? how about anti-screwdriver? would you sit on the fence about a tape measure?
av, even if we accept the retarded interpretation of the term (somewhat more forgivable from average joe public since s/he has an excuse for not knowing better) as just known-malware scanning, is just a tool - no more and no less... it's a tool that is remarkably good at a narrowly defined set of tasks: detecting known-malware for the purposes of prevention, and connecting known-malware incidents that aren't prevented to expert knowledge of the malware in question (by identifying the malware) for the purposes of diagnosis...
being anti-av is like being anti-hammer or anti-screwdriver (and likewise for being pro-av, pro-hammer, pro-screwdriver)... it's a tool (not a religion or a political party), and there are times when it's the appropriate tool to use... those who would completely drop it in favour of some other supposedly superior technology, those who would complain that they relied on av and it let them down, are the very people who never learned the lesson about how when all you have is a hammer, everything looks like a nail... known-malware scanning is a tool, whitelisting is a tool, sandboxing is a tool, behaviour blocking is a tool, heuristic analysis is a tool, etc, and i use and advise on the use of most all of them - security practitioners better than anyone should understand the importance of having a well equipped security toolbox with a variety of tools for a variety of jobs... only the naive would think that the entire malware problem could be comparable to just hammering nails and thus require just one tool...
and since i do make use of all 3 preventative paradigms, it's hard to imagine how i could simply be pro-av... i'm pro-knowledge - i think people should know their tools, what they can do and what they can't, and know the problem so that they can choose and use the tools appropriately... it's really a shame when people commit the anti-malware equivalent of trying to hammer screws into wood, and not nearly as funny...
given my comments about dancho danchev's anti-av leanings in my previous post, i anticipate there will be a number of people thinking (though not necessarily bothering to say it to my face) that i'm the polar opposite - fanatically pro-av... indeed, this has already happened in the past as there are those who wonder about my sanity, consider me an av extremist, and think i belong on the list of the 6 dumbest people in IT security (an homage to ranum's largely ill-conceived 6 dumbest ideas in IT security)...
let me ask you something, though... does it make sense to be pro-hammer? how about anti-screwdriver? would you sit on the fence about a tape measure?
av, even if we accept the retarded interpretation of the term (somewhat more forgivable from average joe public since s/he has an excuse for not knowing better) as just known-malware scanning, is just a tool - no more and no less... it's a tool that is remarkably good at a narrowly defined set of tasks: detecting known-malware for the purposes of prevention, and connecting known-malware incidents that aren't prevented to expert knowledge of the malware in question (by identifying the malware) for the purposes of diagnosis...
being anti-av is like being anti-hammer or anti-screwdriver (and likewise for being pro-av, pro-hammer, pro-screwdriver)... it's a tool (not a religion or a political party), and there are times when it's the appropriate tool to use... those who would completely drop it in favour of some other supposedly superior technology, those who would complain that they relied on av and it let them down, are the very people who never learned the lesson about how when all you have is a hammer, everything looks like a nail... known-malware scanning is a tool, whitelisting is a tool, sandboxing is a tool, behaviour blocking is a tool, heuristic analysis is a tool, etc, and i use and advise on the use of most all of them - security practitioners better than anyone should understand the importance of having a well equipped security toolbox with a variety of tools for a variety of jobs... only the naive would think that the entire malware problem could be comparable to just hammering nails and thus require just one tool...
and since i do make use of all 3 preventative paradigms, it's hard to imagine how i could simply be pro-av... i'm pro-knowledge - i think people should know their tools, what they can do and what they can't, and know the problem so that they can choose and use the tools appropriately... it's really a shame when people commit the anti-malware equivalent of trying to hammer screws into wood, and not nearly as funny...
Tags:
anti-av revolt
the ongoing n.runs saga
you my recall my previous post about n.runs... well, it seems i wasn't the only one who saw FUD as ryan permeh wrote on mcafee's blog about what n.runs was saying specifically about mcafee... now it seems that thierry zoller of n.runs has responded to the mcafee post, or at least he tried to...
he didn't do a particularly good job of it, however, as despite explaining that the graphs come from data gleaned from publicly available 3rd party vulnerability catalogs (something that was clear from their original press release and not in need of additional explanation), he didn't address the issue that ryan raised about not being able to verify n.runs' figures when looking at the raw data and instead mistakenly or intentionally mislead the reader into thinking that ryan was looking to verify the 800 figure (which was n.runs' own) when it was clear from his post that he was only trying to verify the figures that applied directly to mcafee and that were supposed to come have come from 3rd party databases...
thierry also denied making the claim and/or believing that running av makes you less secure in spite of the fact that an n.runs slide deck i posted about last november makes exactly that claim...
additionally, where ryan claimed there was no evidence of these vulnerabilities in mcafee's product being exploited in the wild thierry responds by saying that it's because of the way the vulnerabilities are reported - apparently ignoring the fact that being used in the wild means there should be malware samples implementing the exploit(s) and that mcafee should have seen some of these by now...
one thing that ryan didn't really bring up and so wasn't addressed by thierry is the absurdity of aggregating the vulnerability count across an entire industry (where the 800 vulnerabilities figure is supposed to come from)... it's not an actionable metric, it doesn't say anything about any particular product or vendor within that industry, and only serves to scare people... this is the kind of marketing that john mcafee (long absent from the company bearing his name) used back in the days of the michelangelo virus (have i just invoked the anti-malware industry's version of godwin's law?)... even if there technically are that many vulnerabilities across the product lines of the entire set of vendors in the av industry, it's an entirely pointless measurement...
and while we're on the subject of marketing, am i the only one whose noticed that dancho danchev has put rather a lot of effort into providing a platform for n.runs to spread their marketing message from? one might wonder if he were still as 'independent' as he claims to be, though a more reasonable explanation might be that his rather obvious anti-av leanings (he's frequently made disparaging insinuations on his blog in the past) have been kicked up a notch so that, given the obvious ammo this 800 vulnerabilities claim could provide to an anti-av agenda, he either doesn't care or isn't aware that it's a marketing message he's helping to spread... given a more recent post where he misleads by misusing terms that someone in his position has no legitimate excuse to mix up (samples != variants != families != signatures, so counts of one can't be compared to counts of another), this latter explanation seems all the more plausible...
he didn't do a particularly good job of it, however, as despite explaining that the graphs come from data gleaned from publicly available 3rd party vulnerability catalogs (something that was clear from their original press release and not in need of additional explanation), he didn't address the issue that ryan raised about not being able to verify n.runs' figures when looking at the raw data and instead mistakenly or intentionally mislead the reader into thinking that ryan was looking to verify the 800 figure (which was n.runs' own) when it was clear from his post that he was only trying to verify the figures that applied directly to mcafee and that were supposed to come have come from 3rd party databases...
thierry also denied making the claim and/or believing that running av makes you less secure in spite of the fact that an n.runs slide deck i posted about last november makes exactly that claim...
additionally, where ryan claimed there was no evidence of these vulnerabilities in mcafee's product being exploited in the wild thierry responds by saying that it's because of the way the vulnerabilities are reported - apparently ignoring the fact that being used in the wild means there should be malware samples implementing the exploit(s) and that mcafee should have seen some of these by now...
one thing that ryan didn't really bring up and so wasn't addressed by thierry is the absurdity of aggregating the vulnerability count across an entire industry (where the 800 vulnerabilities figure is supposed to come from)... it's not an actionable metric, it doesn't say anything about any particular product or vendor within that industry, and only serves to scare people... this is the kind of marketing that john mcafee (long absent from the company bearing his name) used back in the days of the michelangelo virus (have i just invoked the anti-malware industry's version of godwin's law?)... even if there technically are that many vulnerabilities across the product lines of the entire set of vendors in the av industry, it's an entirely pointless measurement...
and while we're on the subject of marketing, am i the only one whose noticed that dancho danchev has put rather a lot of effort into providing a platform for n.runs to spread their marketing message from? one might wonder if he were still as 'independent' as he claims to be, though a more reasonable explanation might be that his rather obvious anti-av leanings (he's frequently made disparaging insinuations on his blog in the past) have been kicked up a notch so that, given the obvious ammo this 800 vulnerabilities claim could provide to an anti-av agenda, he either doesn't care or isn't aware that it's a marketing message he's helping to spread... given a more recent post where he misleads by misusing terms that someone in his position has no legitimate excuse to mix up (samples != variants != families != signatures, so counts of one can't be compared to counts of another), this latter explanation seems all the more plausible...
Tags:
dancho danchev,
fud,
nruns,
ryan permeh,
thierry zoller
Friday, July 25, 2008
i'm going to exploit DNS
which is to say i'm going to exploit everyone's interest in the DNS vulnerability dan kaminsky discovered in order to draw eyeballs... in other words: made you look!...
actually, i read on the recurity labs blog that every computer security blog on the planet had written something about the DNS vulnerability, and since i hadn't done so yet i was technically making a liar out of that blogger and that's no good...
problem is, though, that for the most part i really have nothing to say about the DNS vulnerability... i don't like writing about things i don't know and DNS is one of the many times many things i don't know all that much about...
the disclosure argument that ensued was somewhat familiar territory but it wasn't until i read andre gironda's comments to rich mogull's post about whose interests are being served that things finally crystallized in my mind about this... in a nutshell, the information is such that the vast majority of people have no legitimate need or use for it and so to keep it out of the hands of the black hats it really shouldn't be broadcast for the world to see, but at the same time there are enough people that may have a legitimate need or desire to know the information that any centrally coordinated effort to inform them will fail to include many and will only result in an exercise in elitism...
believe it or not, there's actually an old lesson from the AV field to be learned here because the AV community has had to deal with a very similar situation somewhere on the order of about a million times now... long, long ago they came up with a solution that actually works pretty well: a kind of darknet where links are formed between individuals who know and trust each others motives, competence, and judgment - basically a web of trust for sharing malware samples... the benefits are that the adherents to this approach avoid contributing to the sharing of information/materials with people who have no business handling them while at the same time giving everyone who may have a legitimate need or desire for the information/materials has a fair opportunity (but not a guarantee) to acquire them by virtue of being connected to someone else (or better still, many others) who has the means and desire to acquire it themselves...
it's not a perfect system, of course... there have been some instances where the wrong person was trusted, prompting people to rethink how they decide who to trust... there has also been no shortage of lazy bums who can't be bothered to put in the work necessary to actually earn the trust of at least one of their peers and instead whine about how unfair and elitist it is, like some petulant child who feels entitled to receive whatever s/he asks for... there's nothing stopping them from building the relationships necessary to participate in such a network but some people just don't understand that nothing worthwhile in this world is free...
i really think that the wider security community would benefit from adopting a similar approach to 'disclosure', and certainly in the case of the DNS vulnerability there could have been benefits if such a distributed trust-based network had already been established and was utilized... i say "already been established" because it can take time for a trust-based network to get connected and mature; but really, from a tactical point of view, information/intelligence gathering/sharing in hostile territory (and when we talk about broadcasting things on the global stage, the presence of hostile agents is beyond doubt) requires the use of covert channels such as this...
actually, i read on the recurity labs blog that every computer security blog on the planet had written something about the DNS vulnerability, and since i hadn't done so yet i was technically making a liar out of that blogger and that's no good...
problem is, though, that for the most part i really have nothing to say about the DNS vulnerability... i don't like writing about things i don't know and DNS is one of the many times many things i don't know all that much about...
the disclosure argument that ensued was somewhat familiar territory but it wasn't until i read andre gironda's comments to rich mogull's post about whose interests are being served that things finally crystallized in my mind about this... in a nutshell, the information is such that the vast majority of people have no legitimate need or use for it and so to keep it out of the hands of the black hats it really shouldn't be broadcast for the world to see, but at the same time there are enough people that may have a legitimate need or desire to know the information that any centrally coordinated effort to inform them will fail to include many and will only result in an exercise in elitism...
believe it or not, there's actually an old lesson from the AV field to be learned here because the AV community has had to deal with a very similar situation somewhere on the order of about a million times now... long, long ago they came up with a solution that actually works pretty well: a kind of darknet where links are formed between individuals who know and trust each others motives, competence, and judgment - basically a web of trust for sharing malware samples... the benefits are that the adherents to this approach avoid contributing to the sharing of information/materials with people who have no business handling them while at the same time giving everyone who may have a legitimate need or desire for the information/materials has a fair opportunity (but not a guarantee) to acquire them by virtue of being connected to someone else (or better still, many others) who has the means and desire to acquire it themselves...
it's not a perfect system, of course... there have been some instances where the wrong person was trusted, prompting people to rethink how they decide who to trust... there has also been no shortage of lazy bums who can't be bothered to put in the work necessary to actually earn the trust of at least one of their peers and instead whine about how unfair and elitist it is, like some petulant child who feels entitled to receive whatever s/he asks for... there's nothing stopping them from building the relationships necessary to participate in such a network but some people just don't understand that nothing worthwhile in this world is free...
i really think that the wider security community would benefit from adopting a similar approach to 'disclosure', and certainly in the case of the DNS vulnerability there could have been benefits if such a distributed trust-based network had already been established and was utilized... i say "already been established" because it can take time for a trust-based network to get connected and mature; but really, from a tactical point of view, information/intelligence gathering/sharing in hostile territory (and when we talk about broadcasting things on the global stage, the presence of hostile agents is beyond doubt) requires the use of covert channels such as this...
Tags:
andre gironda,
disclosure,
DNS,
rich mogull,
tactics,
vulnerability
Sunday, July 13, 2008
if i have a whitelist, do i still need AV?
on reading this dark reading article about a texas bank dumping AV in favour of application whitelisting technology i was reminded of an email conversation i had with a reader who was dealing with almost the exact same issue only days earlier... i've come to realize this is a question more and more people are going to be wrestling with as time goes on so instead of expecting them to contact me privately i'm going to answer the question of whether you need AV software if you have a whitelist here... the glib answer is no you don't need it...
of course that answer continues with: you don't need the whitelist either, or your computer for that matter - people survived perfectly fine before any of that stuff existed...
clearly, the glib answer isn't all that useful...
the real answer is that i can't decide for anyone whether they need AV... in practice security has a lot to do with making trade-offs and which trade-off is right for any particular person or organization is best decided by those who would have to live with the consequences of that decision... what i can do, however, is point out weaknesses in both individual technologies and describe some of the benefits of using them together...
it's no secret that known-malware scanners are ill-suited to detection of new/unknown malware, updates can be a hassle for large organizations, and the ongoing subscription fees have in the past seemed like a necessary evil but are increasingly seeming less necessary as application whitelisting works it's way into the mainstream...
of course, as we know from figures provided by bit9, the set of good software is larger and growing faster than the set of malware so a vendor-supplied whitelist will almost certainly be worse from an update point of view (and maybe subscription-wise too)... the customer-editable whitelist is much more palatable in that regard because you only put on it those things you actually need in your production environment... coming up with the initial whitelist (not to mention modifying it if/when the needs of that environment change or when software needs updating) puts the customer in the position of having to decide what's safe or not... certainly one should only trust software from known, reputable sources but those sources aren't perfect (even microsoft has accidentally distributed malware in the past) so the first benefit of continuing to use known-malware scanner even though you've chosen to use a whitelist is that you can check the software you intend to whitelist (as whitelist vendors often do for whitelists they provide)... this is an example of the axiom "trust but verify"...
that alone may not seem like it's enough to warrant keeping the desktop av, however, so consider this: just as known-malware scanners don't recognize everything that's malware, application whitelist software doesn't recognize everything that's a program... will the whitelist software block office macros if the office binaries are on the whitelist? will it block batch, perl, kixstart, etc. scripts if their respective interpreter is on the whitelist? will it block javascript from the myriad of ways it can be launched on the system? as an example, i use the application launch control functionality of sunbelt personal firewall as a whitelist and i discovered quite by accident recently that it does not block individual batch files... a known-malware scanner would detect known malware in a batch file, however, and in an office macro, etc... that's a second benefit of keeping known-malware scanners around in a whitelist deployment, and it's one that applies even at the desktop level...
that's not all though... there's also the issue of exploit code that exploits vulnerabilities in whitelisted applications... if the exploit needs to launch additional applications that aren't on the whitelist then the whitelisting software will have interfered with and potentially blocked the exploit, but what if all the applications it needs are on the whitelist? the whitelisting software would be helpless to stop it but a known-malware scanner might still have at least some chance to do so...
known-malware scanners are weak against that which is novel while application whitelists (assuming no malware gets whitelisted) are weak against that which is exotic... together they're only weak against that which is both novel and exotic... this is the essence of what defense in depth means when it comes to the anti-malware world - not using multiple different scanners but rather using multiple and entirely different types of technology so that the second (or third, or fourth, etc) line of defense can stop at least some of what gets through the cracks in the previous line(s) of defense... it's still up to the people affected to decide whether the benefits of a multi-layered strategy warrant the cost but they should definitely consider it as no technology is an island, perfect unto itself...
of course that answer continues with: you don't need the whitelist either, or your computer for that matter - people survived perfectly fine before any of that stuff existed...
clearly, the glib answer isn't all that useful...
the real answer is that i can't decide for anyone whether they need AV... in practice security has a lot to do with making trade-offs and which trade-off is right for any particular person or organization is best decided by those who would have to live with the consequences of that decision... what i can do, however, is point out weaknesses in both individual technologies and describe some of the benefits of using them together...
it's no secret that known-malware scanners are ill-suited to detection of new/unknown malware, updates can be a hassle for large organizations, and the ongoing subscription fees have in the past seemed like a necessary evil but are increasingly seeming less necessary as application whitelisting works it's way into the mainstream...
of course, as we know from figures provided by bit9, the set of good software is larger and growing faster than the set of malware so a vendor-supplied whitelist will almost certainly be worse from an update point of view (and maybe subscription-wise too)... the customer-editable whitelist is much more palatable in that regard because you only put on it those things you actually need in your production environment... coming up with the initial whitelist (not to mention modifying it if/when the needs of that environment change or when software needs updating) puts the customer in the position of having to decide what's safe or not... certainly one should only trust software from known, reputable sources but those sources aren't perfect (even microsoft has accidentally distributed malware in the past) so the first benefit of continuing to use known-malware scanner even though you've chosen to use a whitelist is that you can check the software you intend to whitelist (as whitelist vendors often do for whitelists they provide)... this is an example of the axiom "trust but verify"...
that alone may not seem like it's enough to warrant keeping the desktop av, however, so consider this: just as known-malware scanners don't recognize everything that's malware, application whitelist software doesn't recognize everything that's a program... will the whitelist software block office macros if the office binaries are on the whitelist? will it block batch, perl, kixstart, etc. scripts if their respective interpreter is on the whitelist? will it block javascript from the myriad of ways it can be launched on the system? as an example, i use the application launch control functionality of sunbelt personal firewall as a whitelist and i discovered quite by accident recently that it does not block individual batch files... a known-malware scanner would detect known malware in a batch file, however, and in an office macro, etc... that's a second benefit of keeping known-malware scanners around in a whitelist deployment, and it's one that applies even at the desktop level...
that's not all though... there's also the issue of exploit code that exploits vulnerabilities in whitelisted applications... if the exploit needs to launch additional applications that aren't on the whitelist then the whitelisting software will have interfered with and potentially blocked the exploit, but what if all the applications it needs are on the whitelist? the whitelisting software would be helpless to stop it but a known-malware scanner might still have at least some chance to do so...
known-malware scanners are weak against that which is novel while application whitelists (assuming no malware gets whitelisted) are weak against that which is exotic... together they're only weak against that which is both novel and exotic... this is the essence of what defense in depth means when it comes to the anti-malware world - not using multiple different scanners but rather using multiple and entirely different types of technology so that the second (or third, or fourth, etc) line of defense can stop at least some of what gets through the cracks in the previous line(s) of defense... it's still up to the people affected to decide whether the benefits of a multi-layered strategy warrant the cost but they should definitely consider it as no technology is an island, perfect unto itself...
Wednesday, July 09, 2008
lies, damn lies, and statistics
nruns (who, by the way, have a product designed to fix the problem they're playing chicken little over) are reporting that there are 800 vulnerabilities in anti-virus products...
that's a pretty scary number, isn't it? 800... wow...
but wait, that's not 800 vulnerabilities in your av product, or in my av product, that's the aggregate number across more or less all av products... when was the last time anyone reported an undifferentiated vulnerability metric for an entire class of software? when has that even been interesting the the past?
imagine how many vulnerabilities there are in operating systems - not just one operating system, but all of them combined... and while we're imagining this metric lets make sure that we count each distribution of linux independently, just so we can see how high we can make the metric go...
i wonder how many vulnerabilities there are in browsers or media players or word processors... not just individual products but the entire classes... again i'm sure the numbers are big - see how using browsers or media players or word processors become part of the problem? because that is one of the arguments nruns is making - security software increases the attack surface and therefore makes you less secure... something which obviously completely ignores the positive contributions they make to security - you need to examine both positive and negative contributions, folks... you have balanced a checkbook or budget at some point, right?
while we're examining things, lets examine the independent figures that nruns themselves point out... 50 security advisories for the period from 2002 to 2005, and 170 for the period from 2005 to 2007... first of all, this looks like growth but could just as easily be the result of increased focus on finding vulnerabilities in this class of software... second, 220 (170 + 50) is a far cry from 800... i'd be interested in knowing EXACTLY how that number was arrived at (since such knowledge is how one avoids being mislead by bad statistics)... is each vulnerability distinctly different? if 50 applications have the same vulnerability does it get counted 50 times? if the vulnerabilities were found by forensic analysis of binaries, were any vulnerabilities counted multiple times in the same product due to appearing in multiple places in the code? etc...
at a time when treating the av industry as security's whipping boy is at an all time high, such sensationalistic numbers probably make for good marketing for nrun's product, so long as people don't recognize it for the opportunistic FUD that it is... nruns has what sounds a bit like a scanner sandboxing product which on the face of it sounds like it might be a pretty good idea, but they clearly have a vested interest in making the av industry look bad (because that drives demand for their product) so even if you don't believe the 800 vulnerabilities figure is intentionally poorly defined or an example of opportunistic FUD, you should at least recognize that it's a figure that should be taken with more than a few grains of salt...
that's a pretty scary number, isn't it? 800... wow...
but wait, that's not 800 vulnerabilities in your av product, or in my av product, that's the aggregate number across more or less all av products... when was the last time anyone reported an undifferentiated vulnerability metric for an entire class of software? when has that even been interesting the the past?
imagine how many vulnerabilities there are in operating systems - not just one operating system, but all of them combined... and while we're imagining this metric lets make sure that we count each distribution of linux independently, just so we can see how high we can make the metric go...
i wonder how many vulnerabilities there are in browsers or media players or word processors... not just individual products but the entire classes... again i'm sure the numbers are big - see how using browsers or media players or word processors become part of the problem? because that is one of the arguments nruns is making - security software increases the attack surface and therefore makes you less secure... something which obviously completely ignores the positive contributions they make to security - you need to examine both positive and negative contributions, folks... you have balanced a checkbook or budget at some point, right?
while we're examining things, lets examine the independent figures that nruns themselves point out... 50 security advisories for the period from 2002 to 2005, and 170 for the period from 2005 to 2007... first of all, this looks like growth but could just as easily be the result of increased focus on finding vulnerabilities in this class of software... second, 220 (170 + 50) is a far cry from 800... i'd be interested in knowing EXACTLY how that number was arrived at (since such knowledge is how one avoids being mislead by bad statistics)... is each vulnerability distinctly different? if 50 applications have the same vulnerability does it get counted 50 times? if the vulnerabilities were found by forensic analysis of binaries, were any vulnerabilities counted multiple times in the same product due to appearing in multiple places in the code? etc...
at a time when treating the av industry as security's whipping boy is at an all time high, such sensationalistic numbers probably make for good marketing for nrun's product, so long as people don't recognize it for the opportunistic FUD that it is... nruns has what sounds a bit like a scanner sandboxing product which on the face of it sounds like it might be a pretty good idea, but they clearly have a vested interest in making the av industry look bad (because that drives demand for their product) so even if you don't believe the 800 vulnerabilities figure is intentionally poorly defined or an example of opportunistic FUD, you should at least recognize that it's a figure that should be taken with more than a few grains of salt...
Tags:
anti-virus,
nruns,
vulnerability
Monday, July 07, 2008
the future of malware past
in the two most recent posts on eset's threatblog david harley has been talking about old malware... i don't just mean a couple months or even years old - seriously old malware from over a decade ago that none-the-less continues to cause problems for people...
in the first post david asked how this could be (and in the second pointed out that my answer was to more of a 'why' question than a 'how' one - just the kind of kick in the butt i need to remember to think twice and speak once)...
indeed, if you've got an on-access scanner you ought to be protected from old malware without even thinking about it, right? that simplistic view is certainly what most people have learned but if the infected disk isn't accessed until the computer is booting (a time when neither the on-access scanner nor the operating system itself are loaded yet) then that same simplistic view is proven to be a false sense of security...
that being said, the reason people don't think about or talk about or otherwise take special cases like this into consideration is the widespread (and false) belief that malware eventually becomes extinct... i've already stated numerous times that old viruses never die but what harm could that little mental shortcut really do? well, for one thing when left unchallenged it becomes a dominant pervasive belief... a belief so strong that certain best practices and safe hex behaviours like manually scanning disks before using them even though they're from your own backups or changing the boot priority in the BIOS to prevent possible boot sector infectors from getting an opportunity to execute fall out of common use and knowledge... a belief so strong that vendors may actually remove virus signatures from their signatures databases for performance reasons and eventually allowing viruses that have no good reason to still be around to once again cause problems for many people...
on the other hand, there's no way any reasonable person would accept a belief system that says old malware remains as much a threat now as it did when it was first released, so how should we think about this problem? i suggest that we think of old malware the way we think of landmines - long forgotten and unused but not entirely gone, and one false step and you may be hosed...
this goes for all malware, however one may rightly suggest that some malware won't age as well as others... malware that relies on some sort of infrastructure probably won't do so well in 10 years (when it's command and control network no longer exists or no one's listening to the domain it sends it's logs to)... older (pre-commercial) malware didn't tend to rely on such things though and viruses (due to their infectious nature) are more likely to find their way into backups and so be re-encountered weeks/months/years later... BSI's specifically may well prove to be the longest lived in practice because of their independence from and execution priority over the OS or most any other software component of the system... and of course since they're some of the oldest viruses (the first pc virus was a boot sector infector) and one of the first types to fall out of fashion, and since they're still causing problems, they're already off to a fine start...
foolishly forgetting or recklessly ignoring the the threat posed by old malware will ultimately make utilizing backups, archives, and just plain old media a bit like strolling through a minefield without a map... old malware won't go away, it will just lie dormant in the nooks and crannies of the computer world until we take that one wrong step and it comes back anew...
in the first post david asked how this could be (and in the second pointed out that my answer was to more of a 'why' question than a 'how' one - just the kind of kick in the butt i need to remember to think twice and speak once)...
indeed, if you've got an on-access scanner you ought to be protected from old malware without even thinking about it, right? that simplistic view is certainly what most people have learned but if the infected disk isn't accessed until the computer is booting (a time when neither the on-access scanner nor the operating system itself are loaded yet) then that same simplistic view is proven to be a false sense of security...
that being said, the reason people don't think about or talk about or otherwise take special cases like this into consideration is the widespread (and false) belief that malware eventually becomes extinct... i've already stated numerous times that old viruses never die but what harm could that little mental shortcut really do? well, for one thing when left unchallenged it becomes a dominant pervasive belief... a belief so strong that certain best practices and safe hex behaviours like manually scanning disks before using them even though they're from your own backups or changing the boot priority in the BIOS to prevent possible boot sector infectors from getting an opportunity to execute fall out of common use and knowledge... a belief so strong that vendors may actually remove virus signatures from their signatures databases for performance reasons and eventually allowing viruses that have no good reason to still be around to once again cause problems for many people...
on the other hand, there's no way any reasonable person would accept a belief system that says old malware remains as much a threat now as it did when it was first released, so how should we think about this problem? i suggest that we think of old malware the way we think of landmines - long forgotten and unused but not entirely gone, and one false step and you may be hosed...
this goes for all malware, however one may rightly suggest that some malware won't age as well as others... malware that relies on some sort of infrastructure probably won't do so well in 10 years (when it's command and control network no longer exists or no one's listening to the domain it sends it's logs to)... older (pre-commercial) malware didn't tend to rely on such things though and viruses (due to their infectious nature) are more likely to find their way into backups and so be re-encountered weeks/months/years later... BSI's specifically may well prove to be the longest lived in practice because of their independence from and execution priority over the OS or most any other software component of the system... and of course since they're some of the oldest viruses (the first pc virus was a boot sector infector) and one of the first types to fall out of fashion, and since they're still causing problems, they're already off to a fine start...
foolishly forgetting or recklessly ignoring the the threat posed by old malware will ultimately make utilizing backups, archives, and just plain old media a bit like strolling through a minefield without a map... old malware won't go away, it will just lie dormant in the nooks and crannies of the computer world until we take that one wrong step and it comes back anew...
Tags:
boot sector virus,
david harley,
eset,
malware,
virus
Saturday, July 05, 2008
the malware plateau
i'm sure the title of this posts makes it pretty clear i'm referring to findings recently posted on the mcafee blog by toralv dirro that show that malware growth is slowing... matt hines has also written about it wondering and postulating about what might be going on...
while it still may be too early to tell exactly what's going on, the very idea that it might be even just temporarily slowing down has brought to mind an interesting train of thought:
there's no question that the set of all malware has undergone incredible growth in numbers over the past several years... just as unquestionable, though, is the fact that the resources being consumed in order to affect the apparent exponential growth in malware numbers are themselves either fixed or growing at a significantly less than exponential rate... by resources, i'm not just talking about money (though that certainly is part of the equation) but also man power, time, the pool of susceptible marks, etc...
reaching a point of equilibrium was a foregone conclusion... even if this isn't that point, a plateau like this is inevitable...
while it still may be too early to tell exactly what's going on, the very idea that it might be even just temporarily slowing down has brought to mind an interesting train of thought:
exponential growth (in anything) is not sustainable indefinitely
there's no question that the set of all malware has undergone incredible growth in numbers over the past several years... just as unquestionable, though, is the fact that the resources being consumed in order to affect the apparent exponential growth in malware numbers are themselves either fixed or growing at a significantly less than exponential rate... by resources, i'm not just talking about money (though that certainly is part of the equation) but also man power, time, the pool of susceptible marks, etc...
reaching a point of equilibrium was a foregone conclusion... even if this isn't that point, a plateau like this is inevitable...
Tags:
malware,
malware creation,
matt hines,
mcafee,
toralv dirro
Wednesday, July 02, 2008
how not to comment spam
i recently received some comment spam for this blog... that's not altogether unusual, and certainly not noteworthy in itself, but this comment was something else... i think i'll need to show you what i saw:
![[commentspam.png]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisk_6fzc1eST-UrEsD2qIVxU96v6BX5iT8CK_mkUg4o1pHzvOD_a0vqC5ZBotd03PWfssaqM4OYyljWo3elviWmy_y8m8XH2w8d_tP2ppNB_yThqL0y9d_y180o97O42lEJpYh7A/s1600/commentspam.png)
now i've seen a number of things over the years that have triggered my internal spam detecter (including people trying to put html tags in the name field - a great way to get your comment rejected, just so you know) but never has anyone put in so much individual effort into blowing smoke up my ass...
add to that the name this person entered: seo is a common abbreviation for search engine optimization which is something that comment spammers try to accomplish...
and of course, the most obvious sign of them all, the link that has nothing to do with the article the commenter was commenting on nor the comment itself... links that aren't a natural part of the conversation shouldn't go in the comment... if you want to raise awareness for a site, stick the url in the website field of the comment form...
in fact, if you really want to successfully raise awareness for something, take a look at rob lewis' comments... it became clear to me rather quickly that rob trying to drum up interest in a product but i accepted his comments anyways... why? because he asked questions, he asked for opinions, he engaged in conversation and posted links in a manner that fit with the conversation... in short he was an evangelist rather than a mindless comment spammer...
oh well, just more grist for the lolthreats mill i suppose...
![[commentspam.png]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisk_6fzc1eST-UrEsD2qIVxU96v6BX5iT8CK_mkUg4o1pHzvOD_a0vqC5ZBotd03PWfssaqM4OYyljWo3elviWmy_y8m8XH2w8d_tP2ppNB_yThqL0y9d_y180o97O42lEJpYh7A/s1600/commentspam.png)
now i've seen a number of things over the years that have triggered my internal spam detecter (including people trying to put html tags in the name field - a great way to get your comment rejected, just so you know) but never has anyone put in so much individual effort into blowing smoke up my ass...
add to that the name this person entered: seo is a common abbreviation for search engine optimization which is something that comment spammers try to accomplish...
and of course, the most obvious sign of them all, the link that has nothing to do with the article the commenter was commenting on nor the comment itself... links that aren't a natural part of the conversation shouldn't go in the comment... if you want to raise awareness for a site, stick the url in the website field of the comment form...
in fact, if you really want to successfully raise awareness for something, take a look at rob lewis' comments... it became clear to me rather quickly that rob trying to drum up interest in a product but i accepted his comments anyways... why? because he asked questions, he asked for opinions, he engaged in conversation and posted links in a manner that fit with the conversation... in short he was an evangelist rather than a mindless comment spammer...
oh well, just more grist for the lolthreats mill i suppose...
Tags:
comment spam
take my content, please!
rich mogull exacted his revenge against a blog scraper today by calling the scraper out on his blog and thereby getting that scraped and put on the scraper's site...
i've seen people complain about scrapers before but i just don't get it, especially when they're not monetizing their own content in the first place...
now, i have no idea if the scraper in question also scrapes this blog but i know there are others who do and it's never really bothered me... that's not because i'm a crank (though i know some people like to think so) or because i'm desperate for readers... it's because (perhaps counter-intuitively) i don't write content for the purposes of drawing people to my blog...
i write content for precisely 2 reasons - to get things off my chest and to share what i know and neither of those things are negatively impacted by scrapers republishing my content... in fact, republishing actually helps me share what i know because it makes the information (rather than just links to my site) easier to find by virtue of being in more places...
and if they're selling ads around my content? even better, they have an extra monetary incentive to spread the word of kurt and the money doesn't come out of my pocket...
i'm not trying to monetize my content and i'm not trying to build a brand out of my content... i want people to learn and i have no interest in trying to control how or where they get the information i try to make available...
this isn't to say that other people with other motives shouldn't have the right to try and control such things about their own content, mind you, i just think trying to exert such control is silly...
so with that in mind, to all you scrapers out there - if you want to republish my content then you're free to do so...in fact it was one of the possible uses i had in mind when decided on which creative commons license to use... my only request (and it is just a request) is that you use the full content, not partial text feeds... i despise those abridged post summaries as they ruin the usability of the message (far more than my wacky writing style does)...
i've seen people complain about scrapers before but i just don't get it, especially when they're not monetizing their own content in the first place...
now, i have no idea if the scraper in question also scrapes this blog but i know there are others who do and it's never really bothered me... that's not because i'm a crank (though i know some people like to think so) or because i'm desperate for readers... it's because (perhaps counter-intuitively) i don't write content for the purposes of drawing people to my blog...
i write content for precisely 2 reasons - to get things off my chest and to share what i know and neither of those things are negatively impacted by scrapers republishing my content... in fact, republishing actually helps me share what i know because it makes the information (rather than just links to my site) easier to find by virtue of being in more places...
and if they're selling ads around my content? even better, they have an extra monetary incentive to spread the word of kurt and the money doesn't come out of my pocket...
i'm not trying to monetize my content and i'm not trying to build a brand out of my content... i want people to learn and i have no interest in trying to control how or where they get the information i try to make available...
this isn't to say that other people with other motives shouldn't have the right to try and control such things about their own content, mind you, i just think trying to exert such control is silly...
so with that in mind, to all you scrapers out there - if you want to republish my content then you're free to do so...in fact it was one of the possible uses i had in mind when decided on which creative commons license to use... my only request (and it is just a request) is that you use the full content, not partial text feeds... i despise those abridged post summaries as they ruin the usability of the message (far more than my wacky writing style does)...
Tags:
administrivia,
rich mogull
Subscribe to:
Posts (Atom)