mailing list archives
RE: Norton AntiVirus 2004 Script Blocking Failure (Rant and PoC enclosed)
From: Garth Stone <garth.stone () gmail com>
Date: Sat, 16 Oct 2004 11:12:46 +1000
1. If you submit the scripts setting off the script blocking feature
to Symantec, they will add an exlusion to the definitions -
"Follow the instructions in the document How to submit a file to
Symantec Security Response using Scan and Deliver to quarantine and
submit Server.vbs to Symantec Security Response. Symantec Security
Response will add an exclusion for the file in an upcoming LiveUpdate"
2. Is it the 2004 version your using, because the 2005 version has
been modified to include process protection. To make it more robust
against viruses that try to shutdown its processes. I imagine this
would stop your script as well.
On Fri, 15 Oct 2004 11:14:19 -0400, Daniel Milisic
<dmilisic () myrealbox com> wrote:
For the last couple of week's I've been hands-and-face into a project
that is based heavily on .HTA apps. Basically, the VBScript embedded in
the HTA handles the front-end for some basic console-driven tools. It
was also designed to be very simple as to work equally well under
95+IE5.5 to Win2003. Worked really nice... HOWEVER during the testing
phase on various platforms, I discovered my .HTA grinds to a halt on
machines running Norton AntiVirus 2004, thanks to the "Script Blocking"
feature. A prompt or alert from the damn AV software was NOT something
I wanted my users to deal with. So, I downloaded the TrialWare version
from Symantec to take a poke at whether or not I could work around it.
Here's how that went...
One 25MB Download and I was all set to start testing! But wait, I
LiveUpdate, 4MB -- REBOOT #1 (*mandatory* restart)
LiveUpdate, 3MB -- REBOOT #2 (Prompt to restart with an option to continue)
LiveUpdate, 1MB -- REBOOT #3 (Right now I am thinking oh you have got to
be <bleep>ing kidding me, THREE REBOOTS for an up-to-date AV install!?)
Grisoft's AVG6, for comparison sake, is about 7MB in total I believe,
and requires a single reboot. It doesn't have Script Blocking, but if
you're thoughtless enough to click on a .vbs e-mail attachment you
pretty much deserve what's coming to you ;)
Once out of reboot hell, I fired up the NAV2004 console, an annoyingly
tacky HTA-ish type front-end with more bling-bling than functionality.
Over the last few years I've grown to really dislike NAV for this, and
not just because of the aesthetics. On more than one occasion I'd see a
virus or spyware infected PC with NAV on it (user error not NAV's
fault); with the NAV console just a smoldering pile of script errors
after the malicious program hosed IE's rendering engine. The NAV
Console is built on IE, so if IE gets brain damaged, NAV console is
toast. Oddly (or not) Symantec's Enterprise AV offering uses a more
conventional front-end like just about everyone else. Using IE to help
build nice-looking apps in no time flat is nice, but for AV software
it's just way too critical to have the front-end that far up-the-stack.
I'm way too annoyed with NAV2004 right now to blow up a Windows image to
see if it exhibits the same type of behavior as its predecessors, but it
doesn't look encouraging.
My next gripe is the speed, or I should say lack of. NAV2004 absolutely
cripples older machines. A 500MHz, 256MB PC with AVG or Symantec AV
Enterprise runs tolerably, where NAV renders the machine unusable. It's
that noticeable. I was expecting maybe a little more overhead for the
goofy UI elements, but NAV outright killed this machine's usefulness.
To be fair, the hit is -much- less noticeable on a newer 2+GHz PC but
still there nonetheless.
Application privileges. This is really bad. NAV runs with the
credentials of the logged-in user. Regular NT/XP 'Users' can't
LiveUpdate unless they use something like RunAs to escalate privileges
and do a non-interactive LiveUpdate, typically from scheduled tasks.
This also means if someone with 'User' credentials gets infected, the
virus can kill NAV and keep on partying. Real AV software doesn't
behave like this; it runs with escalated privileges so if a regular user
gets infected the virus isn't able to kill the AV software -- at least
it stands a chance to identify an outbreak if nothing else. And I don't
use this illustration in an Enterprise scenario, I'm talking in the
context of an XP box at home with parents as admins and kids as users.
Here's the zinger I saved for the List... By the looks of it, Norton
AV's Script blocking is trivial to defeat. I don't know if this
behavior is by design but it's so sloppy looking I don't know what to
make of it. Then again, after spending some time with this terrible
piece of AV software, it's consistently bad all the way around so this
glaring problem doesn't really stand out as much as it should.
I can't find jack squat on the 'Net regarding NAV's Script Blocking...
Basically the deal is that you have a Magic Check Box in the NAV Console
that enables NAV to halt a script when it attempts to perform a
potentially "Unsafe" action, say a Document.Write to your HDD. At that
point you can Authorize the single unsafe action inside the script, the
entire script for one run, or permanently "trust" the script. There
doesn't seem to be an editable trust-list or any type of customization
available. Ok, didn't really expect it but I can't even find a way to
add a script to some sort of an exclude list by means of an installer
adding a registry key. I demanded my app run fine with just 'User'
level privileges anyway so it was a moot point, I was hosed. Fine...
forget it. Never mind that even when I did Authorize the script, it
still dies, sometimes crashing mshta.exe along with it! I'm guessing
that's caused more by my bizarro scripting so I'll leave that point alone.
There was a script that didn't get halted which I thought should have
been; a WMI event that did some post-exit cleanup for me. If you're
running NAV2004 here is a little proof-of-concept VBScript to try out.
"CCApp.exe" is the NAV Auto-Protect executable:
--- BEGIN KILLNAV2004.VBS ---
' Feel free to kill "NMain.exe" as well
' to get rid of the hideous console <snicker>
pgm = "CCApp.exe"
set wmi = getobject("winmgmts:")
sQuery = "select * from win32_process " _
& "where name='" & pgm & "'"
set processes = wmi.execquery(sQuery)
for each process in processes
--- END KILLNAV2004.VBS ---
Now... paste, save, and double click KILLNAV2004.VBS -- Did NAV catch
the 'malicious' script or did it go on vacation?
If you ever *do* run a hazardous script in on a box running NAV2004
don't count on Script Blocking to cover your butt.
Symantec should be publicly flogged for trying to sell this inferior AV
software to home users, especially knowing they have a decently workable
AV product in their Enterprise line.
I didn't intend to flame NAV this much but the more time I spent with it
the worse my experience became. It's unbelievable that Symantec sells a
product that operates this poorly!
Full-Disclosure - We believe in it.
Full-Disclosure - We believe in it.