if i have a whitelist, do i still need AV?

Discussion in 'other anti-malware software' started by ronjor, Jul 14, 2008.

Thread Status:
Not open for further replies.
  1. wat0114

    wat0114 Guest

    Hi Kurt,

    could you please explain this? Do you mean authorized via, for example, a checksum?
     
  2. kwismer

    kwismer Registered Member

    Joined:
    Jan 4, 2008
    Posts:
    240
    i mean authorized by whatever means the whitelist/execution control system uses to say 'i know this program, it's allowed to run'... i imagine most well designed ones will in fact have some kind of hash or checksum for each program that's authorized to run in order to make sure it's actually the program it claims to be...
     
  3. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Well, I could spend all of my time hypothesizing what an attacker could or couldn't do, and would become a nervous wreck and would probably join the tinfoil hat club, as it's referred to in another forum. I would constantly be thinking, What if...? So, no thanks:)

    Why should I try the perl interpreter, as you suggest, or install cygwin and try a bash script, when that is totally irrelevant to my system?

    Should I also install Quicktime so I can check out its buffer overflow attack?

    I would rather look at current real attacks (either testing them when possible, or reading an analysis) so I can learn
    1) what the attack vector is so as to determine preventative measures, and

    2) whether or not I'm likely to encounter such an attack. ​

    Often, the probability of 2) is so low that I don't worry.

    This is working from the practical point of view, rather than the theoretical.

    I will say that for me, White Listing all program types not only is not feasible, but not even necessary. There are other ways that I can deal with the attacks against specific applications that I have installed on my system.

    For example, looking the current MSWord attacks, I learn that they are specially targeted to corporate environments as email attachments, with a payload that installs a trojan. Both 1) and 2) above are satisfied, since I still use an old version of MSWord which won't run VBS code; no trojan could install on my system by remote code execution in any event; and I'm not a typical target.

    You comment:

    This assumes much. What if I don't use Outlook? Where did this macro virus come from? Did it just appear out of nowhere?

    Your comments about a virtual machine running on that guest system, VM has network access, router being exploited: How do you know that any of that applies to me?

    The problem with the scenarios you are suggesting is that you have no idea as to how another person's computer is set up, nor that person's computing routines, nor that person's security strategy/procedures.

    One last comment about White Listing: In looking at forums where people come for help in cleaning up infections, it's obvious to me that there are problems more fundamental than whether or not one uses a White List, Black List, or whatever.


    ---
     
    Last edited: Jul 30, 2008
  4. kwismer

    kwismer Registered Member

    Joined:
    Jan 4, 2008
    Posts:
    240
    those were meant to demonstrate the concept that whitelists don't block all program types... i can't give you examples that specifically work on your existing system because i don't know anything about your existing system, that's why i told you to think like an attacker so that that you could come up with examples that would work on your system...

    the 'security mindset' (as it's been called by some) involves thinking about how things fail... if you want to know how the defenses in your setup will fail then you need to think about these sorts of things...

    exploiting software flaws is an entirely different issue... those are unintentional programs, perl scripts (as an example) are intended to be programs...

    indeed there are... AV happens to be one of those ways...

    you're right, i did assume too much... i assumed you'd recognize that as the hypothetical example it was meant to be... only you can come up with examples that work for your system...

    if i were an attacker i wouldn't care about how a person's computer is set up unless i were specifically trying to attack that person... most attackers aren't trying to go after a specific person, they're trying to go after people in general and if the attack works on some of them then that's good enough...

    certainly, but that is outside the scope of a discussion on whether AV is still useful/needed in an environment where whitelisting is being used...
     
  5. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    I agree. I just prefer to look for existing attacks in the wild.
    ________________________________________________________________________​

    Back to your topic as to whether AV is still useful/needed in an environment where whitelisting is being used:
    I don't know that one can make a blanket statement, since examples can be cited to support both views.

    The Love Letter VBS worm for example. AV did not catch the early versions of that worm. I know, because the college where I was working was hit by it -- their AV was up to date -- and it spread rapidly. That afternoon I received an email from our department secretary whose computer had been compromised and sent out the worm to all in her address book.

    While not termed White Listing specifically in those days, anyone who disabled the script engines as part of security -- removing them from executables allowed to run -- was protected if, during a moment of lack of good sense, he/she decided to open the attachment (useful when several people share your computer):

    lovevbs.gif
    ___________________________________________________

    Today's VBS attacks using USB would also be prevented. Some people, as a matter of practice,
    remove scripting engines from the White List in configuring SRP.

    However, for someone who has always used an AV and is now going to employ some type of White Listing,
    I suggest that the person consider carefully before abandoning the AV.


    ---
     
  6. Dogbiscuit

    Dogbiscuit Guest

    I try this, and every time I think up some way to compromise my system, I can think of better ways to avoid the problem than using anti-virus software, like not allowing the file to execute in the first place, like not clicking on the link in the email, etc. What am I missing here? o_O
     
  7. kwismer

    kwismer Registered Member

    Joined:
    Jan 4, 2008
    Posts:
    240
    of course you can't make blanket statements, there are few absolutes in this world...

    true, but not everyone could turn it off (some people actually used vbs and needed vbs), not all script engines can be turned off (ex. batch files), and not all exotic programs are scripts...

    do they remove the command interpreter? USB autorun doesn't always have to use vbs - i have a u3 flash drive that i customized to run an arbitrary batch file, and imagine my surprise when the application launch control feature in sunbelt personal firewall didn't block the batch file (of all the exotic program types i can think of, batch files are the most mundane and well known)...

    if you want to spend your time doing one-off counter-measures for each exotic program type individually then that can work too... it's a lot more tedious though, and (depending on the counter-measures available for the circumstances) it may not be as timely in the case of unexpected program types that result from application vulnerabilities (ie. if the only viable specific counter-measure is applying a patch then you'd be at the mercy of the vendor of the vulnerable application)...

    there are pros and cons to every approach - it's up to the individual to weigh them and choose what's best for them...
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.