You may have seen the news that buzzed around the security community several weeks ago: Daniel Milisic posted a sample script that illustrates how easily Symantec/Norton Antivirus' ("NAV") script blocking can be defeated. His sample script does the following:

1) Sets the NAV Auto-Protect Service to "DISABLED"
2) Sets a registry key to uninstall Script Blocking
3) Creates and launches a VBScript file to download a harmless demonstration program
4) Launches the demonstration program
5) Reboots the PC

The danger, of course, is that a malicious user could craft a tool like this, perhaps disguised as something benign or desirable (a classic "Trojan" hack), to download a destructive or invasive program instead of the harmless demonstration file. What's more, Milisic's sample script is remarkably simple, using no exotic techniques or advanced tricks: It's fully within the skill level of "script kiddies" and other nonprofessional programmers.

Milisic backed into the whole subject more or less by accident when he was writing some Web-page scripts, and wanted to find a graceful way to deal with Script Blockers like Norton's. Instead, he found it was almost trivially easy to completely disable the blocking. To get the word out, he posted four notes on various security-oriented discussion boards:

• Norton Antivirus 2004 Script Blocking Failure
• Norton Antivirus 2004/2005 Script Blocking Redux
• Norton Antivirus 2004/2005 Scripting Vulnerability Pt.3
• Norton Antivirus Script Blocking Exploit--Symantec's response

If you have time to read only one of the above, make it the last one, which is the most comprehensive; summarizing the whole series of posts, offering a link to a video file of the exploit (so you won't have to experiment on a live PC to see it for yourself) and quoting Symantec's response.

That response, while not exactly brushing off the demonstration scripts' import, does downplay it; pointing out that the exploit requires at least some level of user complicity: The user must have Administrator rights, and must somehow launch the initial script.

Milisic regards this response as inadequate because most users do run with Admin privileges; and--as we all know from the proliferation of E-mail-borne worms and viruses--people do click when they shouldn't.

Who's Right?
Strictly speaking, Milisic is right: The scripting problem is real. But more generally speaking, there's not much that Symantec--or anyone--can do about wrongheaded or boneheaded behavior on the part of users. Way too many people don't create a safer, less-privileged account for routine use and instead run all the time in a fully privileged, Admin-level account. This is risky, as any compromising of this account puts the entire system at risk. Plus, many users seem incapable of the minimum self-discipline needed not to click on every random E-mail attachment they get. Whether from boredom, ignorance, or who knows what reason, they click away, opening their PC--and every other PC they communicate with by E-mail or a LAN--to possible attack.

And Symantec certainly isn't alone. For example, firewall vendors face problems caused by user actions or inactions that trigger outbound "leaks" through the firewall, as shown in this test summary. Not a single one of the 10 tested firewalls passed all the "leak tests," and they all failed two of the tests!

Anti-spyware tools? Same thing.

Tests show that no tool catches every form and instance of spyware, all the time.

And it's the same with all other types of security tools, too: There's no tool that's perfect; and no tool that can't be defeated, broken, or disabled in some way, under the right circumstances.

That might sound like a grim assessment, but it's not. In fact, you can infer from it a simple, reliable solution to almost all the problems and limitations with NAV, firewalls, and other security tools.