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

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

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

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

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

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


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


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


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


5. 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!)