It's pretty easy to see where companies get the idea to stop scripts in their environments. After all, some of the most-publicized recent viruses, such as "I Love You," have relied on VBScript and security flaws in other Microsoft products to wreak havoc on file servers, mail servers, networks, and client computers. Most antivirus products, like Norton AntiVirus, now include script-specific functionality to warn users if a script is trying to execute.
I've been fighting these companies a bit on the scripting thing, though. VBScript in particular is an incredibly useful administrative tool. Even the Windows Resource Kit ships with a number of useful scripts to use in migrations and other situations. Shutting down scripting altogether is like outlawing cars because some folks don't drive them responsibly. A better answer would be to get more control over scripting, so that only authorized, trusted scripts are allowed to run.

No, Not That Way
Controlling scripts certainly isn't a new idea. I've seen a number of techniques for doing so, some more effective than others. The first involves a batch file or login script that's used to delete WScript.exe and CScript.exe, the two executables that implement WSH and actually execute scripts. The problem is that these files are under Windows File Protection (WFP) on Win2000 and higher machines. After they're deleted, WFP quickly figure out what you've done and puts them right back where they came from. Also, simply deleting the files doesn't stop an attacker from sending along their own copy, which will execute just fine.

A slightly more sophisticated approach is to use Group Policy or another registry hack to disassociate the script filename extensions -- WSH, SCR, VBS, VB, JS, WSC, and a half-dozen others -- from the WSH executables. That way, users can't simply double-click a script file to execute it. You can still authorize scripts in your environment, either by assigning a new filename extension -- such as XYZ -- and associating it with WScript.exe, or by simply executing WScript.exe directly and passing it the name of the script to execute: WScript.exe MyScript.txt. The problem there is that intruders can use the same trick, sending along a batch file in an e-mail that executes whatever script they need.

A Little Bit Better
Windows XP and Windows Server 2003 offer a slightly better solution in the form of Software Restriction Policies (SRP), a new component of Group Policy that allows administrators to restrict the software that runs on computers. The problem is that SRP makes it really tough to stop all unauthorized scripts. Basically, you can use SRP to set a default condition for unknown software: Allow it to run, or not. You can then define various rules that identify specific pieces of software, and allow them to run or not. The rules can identify software based on an executable file path, a hash, a code-signing certificate, or an Internet zone.

The problem is that there's no way to create a rule for unknown software; unknown software falls under the system's configured default policy. If you set that policy to Disallowed, then you'll have to create a specific rule for every piece of legitimate software that users need to run. Yuck. SRP is great for stopping users from running specific software -- like games or Napster-like software -- but it takes a real effort to use SRP to stop all unknown software from running.

WSH 5.6 to the Rescue
Fortunately, WSH 5.6 offers a better method. First, you'll need to actually obtain 5.6 from the Microsoft Scripting Web site here. It's provided as an MSI, so you can deploy it to client computers by using Group Policy, logon scripts or whatever you like. It'll run on Windows 95 and later, and actually comes preinstalled with WinXP and Win2003.

Once deployed, you'll also need to push out a registry key: \HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows Script Host\Settings\TrustPolicy. This is a DWORD value, and can be set to one of the following:

• 0: Allow all scripts to run.
• 1: Allow trusted scripts to run, and prompt users before running untrusted scripts.
• 2: Allow only trusted scripts to run.

"2" is clearly the winner, as it prevents users from mistakenly allowing untrusted scripts—like viruses—to run on their computers. All copies of WSH 5.6 are governed by this registry key, so even if a user picks up additional copies somewhere, you're covered. And WSH is still under WFP on Win2000 and higher, so attackers won't be able to easily replace WSH 5.6 with an older version.

So it all comes down to, "What is a trusted script?" Another feature of WSH 5.6 is the ability to use a digital code-signing certificate to digitally sign a script. Signing a script doesn't encrypt it, but it does identify the script author (or at least the script signer), and it does ensure that the script hasn't changed since it was signed. If the script's code changes, the signature becomes invalid. Right now, you have to use a script to sign other scripts, as Microsoft hasn't actually provided a graphical script-signing tool. You can find an easy-to-use sample on Microsoft's Web site here.

Simply signing a script, however, doesn't make it trusted. When you sign a script, you use a digital certificate. That certificate is issued by a Certification Authority (CA), someone you trust to accurately verify someone's identity before issuing them a certificate. You can obtain certificates from commercial CAs like VeriSign, Thawte, and others; you can also issue certificates from an internal CA, such as a Win2003 server running Certificate Services. And not just any certificate will do: You have to have one that's marked as being approved for code signing.

It's the CA that issues the script that you trust. For example, all Windows computers are configured out of the box to trust certificates issued by VeriSign and a handful of other commercial CAs. Figure 1 shows some of the CAs that Windows trusts out of the box for code signing; you can access this dialog from the Internet Options control panel application. Simply go to the Content tab and click Certificates.

Here's where you can hit a snag with the whole "trusted" thing: You have to decide if you really do in fact trust each of these commercial CAs. Remember, trusting means that you believe they do a good job of verifying someone's identity before issuing a certificate. Once configured to run only trusted scripts, WSH 5.6 will run any script that has been signed by using a code-signing certificate issued from a trusted CA. If, for example, you think one of these commercial CAs does a horrible job of verifying identity, then you should remove them from your users' trust list. You can do this through Group Policy on Win2000 and higher machines.

You can also configure your client computers to trust your own internal CA, and issue yourself a code-signing certificate to use to sign scripts. That will make your scripts trusted and allow WSH 5.6 to execute them.

Dangerous Trusted Scripts
Yes, there's nothing stopping an attacker from buying a code-signing certificate from VeriSign, signing a malicious script, and e-mailing to every user in your company. You know one of them is going to execute the thing, and you've got a virus on the loose. But, since the script was trusted, you can find out who sent it. Tools are available to examine the script's embedded signature, and that'll tell you who issued it, and who used it. If the CA did a good job of verifying the signer's identity prior to issuing the script, then you'll be able to track them down through the CA and take appropriate legal actions against them, if necessary.

All Safe on the Scripting Front
There's nothing stopping you from taking several of the steps I've outlined. You can disassociate the common script filename extensions, deploy WSH 5.6 and configure it to run only trusted scripts, and even lock down with SRP if you like. The point is that scripting can be made safe and controllable, particularly through the use of WSH 5.6's trusted scripts functionality, allowing scripts to remain a useful, beneficial administrative tool while protecting users from script-based viruses sent by unknown attackers.