lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <416F7ABB.8070502@myrealshoebox.com>
Date: Fri, 15 Oct 2004 03:22:35 -0400
From: Daniel Milisic <dmilisic@...ealshoebox.com>
To: full-disclosure@...ts.netsys.com
Cc: bugtraq@...urityfocus.com
Subject: Norton AntiVirus 2004 Script Blocking Failure (Includes PoC and rant)


Hi All,

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 
should LiveUpdate...
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 to get up-to-date AV installed!)

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
  process.terminate
 next
--- END KILLNAV2004.VBS ---

Now... paste, save, and double click KILLNAV2004.VBS -- Did NAV catch 
the 'malicious' script or did it go on vacation?

SUMMARY:

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 was.  It's hard to believe it's this bad.

Regards,
D.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ