Vulnerability in Microsoft Video ActiveX control could allow remote code execution

That article includes a “Fix it” link that users can click on to disable the exploited ActiveX objects in Internet Explorer. The link downloads a small installer file which users can only execute if they are logged on as administrators. So deploying using that link would require that an administrator log on to each computer, including servers, and run the installer.

How can I quickly deploy this patch to all systems that I manage? I could follow the instructions in the related TechNet article to manually set up a .reg file, then deploy that with logon scripts or group policy. That article at least confirms that the fix is changing HKEY_LOCAL_MACHINE entries, so it’s not user-specific. I decided instead to deploy the installer using a Zenith job. Here’s how.

1. Make the Install File Accessible

1a. Download the 645KB MicrosoftFixit50287.msi from the article above.
1b. Upload it to a publicly-available web address.

2. Set Up the Zenith Job

2a. If you don’t have a Global Distribution Point in Zenith yet, define one. In the Zenith portal, go to Job Management > Script Management > Distribution Points > Global and click on Create DP. Set up a link pointing to the location where you stored the file in step 1b:
 

2b. Define the Zenith job. In the Zenith portal, go to Job Management > Script Management > Scripts > Global and click on Create Script. Fill in the fields as shown below.

• Choose any Category you like, or create your own.
• For the Distribution Point, select the location you defined in 2a.
• Make sure you put “MicrosoftFixit50287.msi” in both the Executable File and the Additional Files boxes.
• Make sure to specify the “/quiet” command line parameter, or the job will fail because no user interaction is possible.

3. Deploy the Job

You can deploy the script on one site or several.

3a. For testing, in the Zenith portal, go to Job Management > Script Management > Execute Scripts > Global, choose the Category you selected, choose the script, and follow the wizard to deploy it to one or two machines.

3b. After 15-30 minutes, in the Zenith portal, go to Job Management > Script Mgmt Report > Site Wise and check the execution status. When your test machines show “Success”, check the Event Log on the test machines. You should see the following success event in the Application Event Log:

Event Type:    Information
Event Source:    MsiInstaller
Event Category:    None
Event ID:    11707
Date:        7/7/2009
Time:        12:11:00 PM
User:        NT AUTHORITY\SYSTEM
Computer:    TESTMACHINE
Description:  Product: Microsoft Fix it 50287 — Installation completed successfully.

3c. Deploy globally. In the Zenith portal, go to Job Management > Script Management > Multi Site Job Deployment > Global Script, choose the script, and follow the wizard to deploy it to all Server and Desktop machines. (I didn’t see any issues when I re-deployed it to my test machines.) Set the time period long enough that it will include machines that are currently turned off. Your job definition should look something like this:

3d. Follow job progress. In the Zenith portal, go to Job Management > Script Management > Delete Scheduled Jobs. Under Multi Site Job Deployment: Scheduled Job Details, click on the job to see a list of all machines and their statuses. Once all the jobs complete, they will no longer be listed under Delete Scheduled Jobs; you’ll have to check individual sites under the Script Mgmt Report section.

Bigger Jobs

If you want to deploy other software with larger install packages, you may want to use local FTP distribution points rather than a global distribution point. I blogged about that here.

Zenith Infotech monitoring sometimes downloads files that trip NOD32’s HTTP filter (e.g. SpyBot and BitDefender executables). Zenith recommends excluding “update.itsupport247.net” from antivirus scanning. It’s not hard to do in NOD32, but it is hard to find someone who knows how to do it!

Here’s the basic procedure:

1. Open the NOD32 client interface and press F5 to load the Advanced dialog. Navigate to Antivirus and antispyware > Web access protection > HTTP > Excluded addresses.
2. Add “update.itsupport247.net/*” to the list.

Note:  do not put “http://” in front of the address, but do put “/* ” after it! If you forget the “/*”, the exclusion won’t work:  NOD32 will block Zenith from downloading files.

Deploy Using ESET Remote Administrator Console

Want to deploy that from a configuration file? Here is where things really get strange.

First, even though you don’t own the firewall product, to set up an HTTP exclusion, open the ESET Configuration Editor and navigate to ESET Smart Security, ESET NOD32 Antivirus > Personal firewall > Setup > List of URL addresses excluded from filtering. Click on Edit to add “update.itsupport247.net/*”.

The problem is, when you deploy that, the exclusion will not show up in the client’s user interface if that client has never had an HTTP exclusion. However, if you first set up any HTTP exclusion on the client, then deploy the correct exclusion from the ESET Remote Administrator Console, the correct exclusion will appear on the client.

I have not been able to figure out why the exclusions don’t appear until one is first added to the client. But hopefully, with that annoying manual effort, the exclusion will at least work and allow the clients to download the Zenith updates as necessary.

Zenith provides a decent Job Management Training Guide in PDF format on their partner portal. I just wanted to note a couple things I didn’t see documented:

• Jobs run on a local machine as LOCAL SYSTEM. This account does not have direct network access even to servers on the local network. So if you write a batch file hoping to run an executable from a network share, it will fail with Access Denied (even though the portal will say that it succeeded).
• You could set up a central server to host all updates, but that would mean downloading the update across the wire for each computer. I wanted to use the client’s local server instead. I decided to set up an FTP site on the server with the following restrictions:
  • Use a custom port, e.g. 7214. Do not open this port on the external firewall.
  • Point to a local folder, e.g. D:\FTPDeploy.
  • Anonymous access only.
  • Read access only.
  • Deny access to all computers except local subnet, e.g. 192.168.1.1/255.255.255.0.

Once the FTP site is set up, you’re ready to work in the Zenith portal:

1. Set up a site-specific job distribution point. The server address is the internal IP of the server plus the port, e.g. ftp://192.168.1.2:7214.
2. Set up the script. For example, let’s say you’ve set up the required distribution agreement with Adobe and created a custom setup for Adobe Reader using the Adobe Customization Wizard. You’ll have about six files that are needed for the installation. Copy those files files into a subfolder of D:\FTPDeploy, e.g. CustomAcroRead. Then create a site-specific script in the Zenith portal using the following values:

Distribution Point:  the FTP distribution point you created above

Executable File:  setup.exe (the bootstrap file that Adobe runs to start the custom installation)

Additional Files to be downloaded:  CustomAcroRead\*.*

Command Line Parameters:  (leave blank–the Acrobat Reader installer doesn’t need any parameters)

The Additional Files line is the trick:  it tells the ZDeploy process to download all the files in the CustomAcroRead subfolder to the local computer’s C:\Program Files\SAAZOD\Executables folder. Once they are there, it will run the Execute File specified. Do not add the CustomAcroRead subfolder before the Executable File’s name or the executable will not be found.

1. Open a command prompt and type
   sc create CmdSvc binpath= "cmd /K start" type= own type= interact
sc start CmdSvc
   Attempting to start the service will fail with error 1053 because CMD doesn't have any service-related code. However it will also open a new CMD window running as LOCAL SYSTEM.
2. Do your testing in the new CMD window.
3. When you're done, you might want to get rid of the service:
   sc delete CmdSvc

Thanks Adi

A.S.E. scripting is still fairly new in the Zenith offering, and definitely takes some getting used to. Here are a few things that I’ve learned along the way. I’ll cover five topics:

Script Parameters
INI Files
Helper Scripts
ITS Variables and the SAAZ Extended Database
When Scripts Run
MD5 Checksums

Script Parameters

The Zenith agent runs Automise scripts using Automise’s ATCMD command-line utility. One powerful feature of command-line execution is the ability to initialize script variables using command-line parameters.

For example, let’s say you write a script to send an email. Rather than hard-code the SMTP host, port sender, recipient, etc., you want to use parameters to supply that information.

1. In Automise, define the parameters as normal variables, e.g. SMTPHost, SMTPPort, SMTPSender, etc.
2. When creating the Send Email action, use the parameters in the appropriate fields, e.g. in the Host field type %SMTPHost%. If the field is a drop-down (like SMTP Port), you’ll have to add code manually. With the Send Email action highlighted, click on the Script Editor tab, then on the Before Action tab. Add the following line:
   Action.Port = CInt(SMTPPort)
3. To test the script, you can either supply default values to the parameter variables and run from inside Automise, or you can use ATCMD to run the script from a command line. This ATCMD example sends output to a text file and sets two variables (parameters):
   atcmd /PSendEmail.zatz3 /LSendEmail.txt /VSMTPHost=”smtp.myserver.com”;SMTPPort=25
4. When defining the script in the SAAZ portal, add one Command Line Parameter for each variable that you want to pass in to the script. Add the parameters in this format:
   SMTPHost="smtp.myserver.com"

Parameter Length

When running scripts on demand, I have yet to encounter a limitation on how many parameters can be supplied or how long they can be. However, the same script that works fine on demand may fail when run from a template. In the ACM Execution Health Status report, on the Success/Failure Details tab, you will see this message:

Postprocessing:Exit with return code: 14 (ERRORSETTINGVARIABLE)

If you hunt down the text log of the script execution in the C:\Program Files\SAAZOD\AutomiseLogs directory, you will see a short log listing a few of your variables and ending with the line:

Error - variable doesn't exist:

At this point you may already suspect that the command line was truncated, which would mean that the script could not initialize all of your variables. Further sleuthing will lead you to C:\Program Files\SAAZOD\ApplicationLog\SAAZScheduler.log. Search for the name of the failed script and you should see the truncated command line. You can see command lines for upcoming scheduled executions in C:\Program Files\SAAZOD\Configuration\SAAZScheduler.ini.

Zenith support tells me that the command line limit was 300 characters. On one machine where I had this issue, they installed an updated SAAZScheduler.exe (version 5.0.0.6 dated 5/11/09) that reportedly allows command lines up to 1000 characters. The new version did in fact solve the problem.

Update 6/5/2009: Zenith deployed the updated components to all agents a couple weeks ago. Since then, I haven’t had any parameter length issues.

INI Files

Another way to set script variables is to retrieve them from an INI file using the Load Variables from INI action. How do you get them into the INI file in the first place? With the Save Variables to INI action.

For example, you could write a script to store all the needed SMTP variables in an INI file. Run that script on each computer you manage, and each computer will have a copy of your custom INI file. Then you can retrieve those variables from the INI file whenever you need to send an email.

Helper Scripts

One very interesting feature of Automise is the ability to “call” scripts from other scripts. These are referred to as helper scripts, support scripts, or dependent scripts.

In Automise, you call the helper script using the Include Project action. You can pass variables from the calling script to the helper script.

In Zenith, you first define the helper script as a stand-alone script. The script can have its own parameters. Then you define the calling scripts, and under Additional Script File Name, choose the helper script from the drop-down list.

I use a helper script to send email. The helper script is responsible for retrieving SMTP variables from an INI file and sending the email. The calling script passes the message subject, message body, and optionally the attachment name to the helper script.

Where Is That Script?

In order to call a helper script, you’ll need to know where the SAAZ agent stores it after downloading it. If you look for scripts in the SAAZ agent directory, you may find them in this folder:

C:\Program Files\SAAZOD\ProcessedScripts

In a script built from the SAAZBaseScript, that folder is available as a variable named “Agent-downloaded-script-directory”. However, Zenith support pointed out that scripts are only stored in this directory when they are scheduled using templates. On-demand scripts are never stored there, so references to scripts in that directory may fail.

It turns out that for on-demand execution, the Zenith agent temporarily stores the primary and helper scripts in this directory:

C:\Program Files\SAAZOD\ATCMDExecutables

I say “temporarily” because I was only able to determine this by listing the contents of this directory from inside a script. Once the script completed, the directory was empty again.

The good news is that in both cases, the helper scripts are in the same directory as the primary script. This means that you can use Automise’s built-in “PROJECTDIR” variable. This variable identifies where the calling script is running, so it is also the location of the helper scripts. To specify the helper script, in the Include Project action, use PROJECTDIR plus the script name, for example:

%PROJECTDIR%\SendEmail.zatz3

ITS Variables and the SAAZ Extended Database

Each script can optionally upload the contents one or more variables to the SAAZ Extended Database, which can be a handy way to check the output from scheduled scripts. Just create a variable with a name starting with “ITS_”. When the custom action Post ITS Variables to SAAZ Data Center runs, the variable’s contents will be uploaded to the SAAZ Extended Database. (Post ITS Variables to SAAZ Data Center is part of the SAAZBaseScript, which you use as a starting point for all your scripts.)

For example, if I create a variable named “ITS_AVStatus”, in the SAAZ Extended Database screen, for each machine that runs the script, I will see a variable named “AVStatus” and whatever value was supplied by the script. Values are limited to 100 characters.

Some gotchas on ITS variables:

• As of this writing, you cannot delete variables once they are in the SAAZ Extended Database. Use sparingly!
  Update 6/5/2009:  ITS Variables can now be deleted. (Thanks Zenith!)
• Scripts cannot download ITS variables. This means you cannot access yesterday’s value from the SAAZ Extended Database when you run the script today. (The Get SAAZ Variables action at the beginning of the SAAZBaseScript sets local variables; it does not get values from the SAAZ Extended Database.) If you need to access data from the previous script execution, you’ll need to store the data on the local machine. One easy way to do that is using INI files (see above).

When Scripts Run

When you schedule an on-demand script, you give it a time window starting from now to any point in the future (even years from now). The script will run one time. If the target machine is not online, the script will run when it is turned on and checks in, as long as it checks in before the Till Date.

On the other hand, when you schedule recurring scripts using templates, you define a specific time for the script to run. If the machine is offline at that time, that execution is skipped

MD5 Checksums

If you are writing and updating a lot of scripts, you will need to calculate lots of MD5 checksums for publishing the script in the Zenith portal. Zenith includes an MD5 tool, but a faster approach is to use the free BullZip MD5 Calculator:  just right-click on a script in Explorer to get the MD5 checksum.