Wiki Home

Removing Windows Scripting Host


Namespace: Wiki
If you're like me, you've had enough of the endless stream of security problems, like the ILOVEYOU virus, that spead as a result of Microsoft Outlook, Outlook Express, and the Windows Scripting Host.

I've never myself been burned by this, but my poor mother, my poor mother in law, and countless other good people -- family, neighbors, and acquaintances -- who call me asking for computer advice have been burned. I know developers who've been burned! I have one question: Why do these people have WSH installed in the first place? Which sloppy idiot millionaire (or near-millionaire wannabe) at Microsoft is responsible for this? Whoever he or she is, or whoever you are, up yours!-- Steven Black

[2002.01.12] Here's the latest: http://www.zdnet.com/zdnn/stories/news/0,4586,5101624,00.html

I know a lot of people out there just love the Windows Scripting Host. Hey, power to you. Me, I'm amazed that this piece of crap is still around, silently installed by default as part of the Continuous Obsolescence cycle proscribed by idiot-savants at Microsoft.

For a complete discussion of the pros and cons of removing Windows Scripting Host, see http://www.zdnet.com/products/stories/reviews/0,4161,2573079,00.html

To turn off the Windows Scripting Host, see http://www.zdnet.com/products/stories/reviews/0,4161,2568111,00.html. People, it's okay to say "No" to software you can't trust. My bottom line is this: if your application uses the Windows Scripting Host, I don't want it on my machine. I have no use case for it, and I doubt 99% of people reading this do either. The typical non-developer has no imaginable use for it; that's fact.

-- Steven Black
[2002.01.12] I can't agree with this - do you want to turn off batch file processing as well? Dissallow all .bat and .cmd files? What about com files or exes?

There are plenty of places where the WSH makes life a whole heap easier - here's an example:

I have a client who's shipping software (provided by the shipper) produces a file that each day must be e-mailed or sent on disk back to the shipping company's head office. Because the shipping app is not modifiable by my client, what had to happen each evening was that the despatch clerk would manually e-mail the file to the shipping company. We set up an automated task using WSH to pick up the files from the shipper's folder and e-mail them. If the email was submitted sucessfully, the file is moved to an archive folder. If the WSH had not been installed on the despatch machine, a simple 10 minute job that solves a business need quickly and effectively would either not have been done, or would have needed a larger, less maintainable application developed for a much greater cost.
WSH is not the only or easiest way to e-mail. Download Rick Strahl's wwipstuff.dll and SMTP send e-mail with a few lines of code. - John Ryan

IMO, there's no justification for ditching a technology just because "bad things can happen" - if that were the case, we would still be using abacasus! Nonsense. Think firearms, GM foods, stem cell research, eavesdropping technology, calculators in elementary schools... the list is endless. You can't indiscriminately apply utilitarian thinking like this.

-- Andrew Coates

You prove my point exactly! You've identified that 1% use case that makes WSH merely useful (not indispensible). For the remaining majority, including yourself, the WSH is just waiting to bite you. -- Steven Black

[2002.01.12] Again, I disagree with you here. Firstly you said "The typical non-developer has no imaginable use for it; that's fact" and I showed you a case where a non-developer has a use for it. Secondly everything we do is "merely useful (not indispensible)". Thirdly, I only quoted one use case, but that's not to say there aren't plenty more. Fourthly, you haven't addressed the question of batch files and the great benefit of being able to write advanced batch files with WSH -- something many "non-developers" still need to be able to do. -- Andrew Coates

Steve says "the typical non-developer has no need for WSH". You counter with an anecdotal tale about a non-typical non-developer. How does your counter-argument apply to a typical non-developer? It doesn't. Your argument isn't adressing the same conceptual space. Steve's absolutely right.

This is a vanishingly simple interaction between two servers, copying a file from one folder to another (for crying out loud!), presented as supporting evidence for the wide distribution of WSH. Um, nonsense. Just about any development language, including DOS, can do all of this. It's a silly example, coupled with silly logic, extrapolated to every computer that runs IE and/or Outlook. That, and there is no reason whatsoever for "advanced batch files" in 99.9% (at least) of all PC's. Including mine.

What WSH gives us is a documented back-door, object model and all, a roadmap for hacking into any machine running Microsoft software. I'd like to see a batch file or an EXE file, or any of the other file types you mention, do the sort of systematic and self-perpetuating damage that we're seeing these days. There is no reason whatsoever that an email client should be VBA-enabled by default, and there is no intelligent reason that something like WSH should exist by default to provide yet another layer for controlling my email client. The only VBA code to ever run on my outlook clients (100%) was written by hackers, and I'm willing to bet that this is true for a boggling vast majority of people who run Office or IE (outlook express). -- Steven Black

  • Firstly you have forgotten the e-mailing aspect of the use case - the files are polled for and then sent by e-mail and then only if the e-mail was submitted sucessfully, the files are moved. Not the simplest task with anything other than an advanced scripting engine like WSH.
  • Secondly, contrary to your "I'd like to see a batch file or an EXE file, or any of the other file types you mention, do the sort of systematic and self-perpetuating damage that we're seeing these days", there are plenty of "successfull" viruses that are exe files (or pif files or scr files or whatever).
  • Thirdly if "The only VBA code to ever run on my outlook clients (100%) was written by hackers", then you and your users are missing out on a vast productivity potential. Macros in Office apps are a fanststically useful feature. Popping up dialogs for common fields when starting a letter in Word, automating the formatting and distribution of an excel spreadsheet, creating a presentation in powerpoint based on data and images created or accessed on the fly according to run-time conditions and so on are all extremely useful. Outlook automation is also a real panacea. I have clients that insert information from their outlook inbox into tables at the click of a button in outlook without ever leaving outlook. They don't know that they've instantiaed a COM object, validated and inserted data and sent confirmatory e-mails, they just know that they've clicked a button in their e-mail tool and that next time they open up their CRM software, all that information will be available. -- Andrew Coates
    Bullshit Andrew! Me and my users are missing no "panaceas" -- as if "panacea" can be described as doing anything without leaving Outlook. Firstly nothing you describe requires WSH. Second, Word and Excel VBA macros are wonderfully useful, sure, and I use them all the time. What the hell does that have to do with VBA in Outlook? For every PC that uses Outlook VBA, there are tens of thousands thousands who do not, and there is no way to turn this shit off. The whole notion of installing the ability to iterate a contacts folder by default with no way to turn it off is bogus. The whole notion of installing by default interfaces and an object model to read/write to the registry, format drives, and otherwise execute arbitrary code is borderline unethical.

    I'm not questioning the usefulness of WSH or VBA in Outlook. I'm not saying there are no practical applications; of course there are. I'm not saying it's not "cool" and that computer geeks shouldn't use it. I question the wisdom of installing this shit by default and I'm questioning the need for most people to have it installed at all. We've nixed it everywhere -- this topic is supposed to explain how to do that -- and we don't miss it in the least.-- Steven Black

    You are attacking the wrong problem, the lack of a good default ACL (Access Control List) mechanism is the major culprit. On Windows (excluding the NT branch), all users run with full administrative privileges and any process they execute can take over the whole computer. On a Unix style OS, the user is running with reduced access privileges and there are better controls on the modification of files and execution of processes. Even on The more secure Windows derivatives, most users run with full administrative privileges. This is because there is no Windows equivalent to sudo, which enables a user to execute a command as if they were another user. This allows one with an administrative access to login with restricted privileges for normal operations and to escalate your privileges when needed to perform administrative tasks. -- Albert Ballinger

    No equivalent to SUDO? Er, yes there is ....
    C:\WINDOWS>runas
    RUNAS USAGE:

    RUNAS [ [/noprofile | /profile] [/env] [/netonly] ]
    /user: program

    RUNAS [ [/noprofile | /profile] [/env] [/netonly] ]
    /smartcard [/user:] program

    /noprofile specifies that the user's profile should not be loaded.
    This causes the application to load more quickly, but
    can cause some applications to malfunction.
    /profile specifies that the user's profile should be loaded.
    This is the default.
    /env to use current environment instead of user's.
    /netonly use if the credentials specified are for remote
    access only.
    /savecred to use credentials previously saved by the user.
    This option is not available on Windows XP Home Edition
    and will be ignored.
    /smartcard use if the credentials are to be supplied from a
    smartcard.
    /user should be in form USER@DOMAIN or DOMAIN\USER
    program command line for EXE. See below for examples

    Examples:
    > runas /noprofile /user:mymachine\administrator cmd
    > runas /profile /env /user:mydomain\admin "mmc %windir%\system32\dsa.msc"
    > runas /env /user:user@domain.microsoft.com "notepad \"my file.txt\""

    NOTE: Enter user's password only when prompted.
    NOTE: USER@DOMAIN is not compatible with /netonly.
    NOTE: /profile is not compatible with /netonly.

    -- Alan Bourke

    Uh, hate to jump into into the fray, but I'm going to jump into the fray...

    I can understand limited use of VBA to control apps like Word and Excel. I'd prefer that their scope be limited, but I don't see the proper limitations coming down from on high at Redmond anytime soon. WSH is another matter. I do not, as a matter of principle, use this tool. Instead, I use a couple of tools I learned when working in Linux to do the same job. They are Tcl/Tk and Python. Tcl/Tk can best be describled as "& macros on steroids", as the entire languange is based on the idea of macro substitution. Python is an object oriented language, and is better for larger scale project, though it can act as a scripting language, as well. Between these tools and careful use of the Windows API, I've yet to have need of WHS once.

    ...my two cents, worth, of course.

    David Stowell
    I suppose regular expression support in WSH could come in handy (although I still haven't had the need to use this myself) - so I would agree that having this on by default is dangerous. However, if an application did need the WSH for something, deployment would be a headache if there were not a documented way to turn it on (which would also be a vulnerability, yes/no?) - either that or it would have to be something included in an installation wizard (ie. Install Shield). I primarily stay away from it because it's something I can't be confident is consistent on every PC that I don't have physical or remote access to -- Randy Jean
    I belive all of you wrote this before winxp os was out on the market. XP has a "run as" feature where you can execute a program as another user (even administrator or limited user). If you don't use Antivirus/ AntiSpyware/ Firewall then you're shurely looking for trouble. The beauty of WSH is exactly the fact that its installed by default on most windows systems out there (it can be removed or disabled if desired, by WSH-fobists :)). You can however take precauton measures as to change default action on .vbs files to "Edit" instead of "Open" (on yout users boxes or even yours if you're not used with RightClick->Edit on every reg, vbs, jvs, bat, cmd out there ;)). You can insert a layer between the WScript.exe and the script itself (build an app that will present the option to cancel the run and maybe to show the vbs file script to the user, maybe more advanced features like scaning for posible malicious code and then warn and ask the user) you'll associate your app with the script files and your app (if user is ok with it) will run the WScript.exe passing it all parameters recived. But i'm shure there allready is something similar out there.
    Indeed i haven't been burned with any vbs virus (i'm verry cautious, i check the file), and then again i don't use outlook (don't like it, it has a bad reputation). Office Suite has checks for macros also (i'm satisfied of 2k and above)
    In all, i love it, is a quick and dirty scripting language, that i use can build a routine "on-site" if need's be :)
    Steve, if you don't like it, remove it; remove it from your friends OS's also. Its dangerous if no precautions are taken, i agree, but then again, so is bat, exe, com, pif, scr, and the list goes on .. My advice is to teach people, instead of isolating them from it, that way they will know it, they may be using it, they may devise some usefull-ness from it that could make their life easier, and in the mean time, know how to protect from the "dark side" of it :)
    You can't advocate for its removal from the Windows OS if you don't like it. Advocate for a mallware script scaning&protection/warnig included in the OS (wich XP SP2 seems to have to some extent). SP2 will not run an executable that hasn't been validated by you or signed by an aouthority in the field, also. (i'm not shure if it was in the SP1 too). Cheers!

    - edyshor
    but wait...
    Since I can do much of the same damage as a virus writer without the scripting host versus with, removing the WSH doesn't appear to solve the problems mentioned. It appears that the argument is to get rid of the criminal's handgun so he is forced to use a rifle, when really, we should jail the criminal. -BenCreighton
    I agree to Ben Creighton, you can't enforce Inquisition-like behaviour just because the technology is to powerful and used incorectly could do much damage, it will be re-discovered again in the future, and probably by not-so-well-meaning people, then you'll deprive power-users and administrators of some realy useful tools .. and here again, the solution as i see it is .. education .. an educated user will know what could hapen if he opens that email, he'll know why he has to scan with an antivirus, and how to interpret the scaning results. Remember that the first virus was a "demonstrative" program, to prove that it was posible, and i belive that in the tomorow's internet could prove a valuable tool. I remember reading somewhere about a virus who's only purpose was to clean-up other viruses, while i don't agree with actions like this, you have to realize that the fastest spreading code is, in its essence, a "virus" or a "worm" ..
    - edyshor
    Contributors: Steven Black, Andrew Coates, Albert Ballinger

    Category Windows API Category Windows OS
  • ( Topic last updated: 2006.06.26 06:53:41 AM )