Beware the Briar Patch: Outlook's Latest Security Update -- Part 3
by Tom Syroid07/01/2000
Part 1 | Part 2 | Part 3 | Part 4
As Tom explains in Part 1 of his series, Microsoft's recent Outlook security update, designed to limit the damage caused by the recent rash of worm viruses, was controversial before it hit the streets. Those who worked with the pre-release code complained that the patch broke more than it fixed and its implementation was a disaster.
In this series of articles, Tom guides you through the numerous complexities, contortions, and "gotchas" hidden under the covers of this update. This part covers "The Object Model Guard" and "Security Zones." In Part 4, Tom gives you some valuable recommendations.
The Object Model Guard
Worm viruses replicate by accessing elements of Outlook's Object Model, which in simple terms is a hierarchical structure of functions that one program can use to accomplish some action within another. In the case of Melissa and similar variants, when a user opens an infected message and executes the attachment, the script embedded within the file does two things:
Accesses the Windows Address Book and fetches the email addresses of the first 50 contacts it finds.
Uses Outlook's internal Send function to forward the original message--complete with attachment--to those 50 contacts.
Recent permutations are deadlier still. They email themselves to all contacts in the user's Address Book and busily start destroying local system files. This process has the potential to repeat itself on the system of each contact foolish enough to open the same infected file.
Microsoft's solution to this problem brings us to the second and most contentious component of the SR-1 Security Patch: The Object Model Guard. This "guard" monitors any attempt by an external program to access your Address Book or send email using Outlook. If any such access is detected, a warning dialog appears as shown in Figure 1.
Figure 1: The Object Model Guard access dialog
You must then explicitly check the "Allow access for" option, choose a time period (Options are 1 minute, 2 minutes, 5 minutes, and 10 minutes.), and then click Yes.
So what's considered an "external" program? The distinction is very clear: any non-Outlook program. This list includes PDA synchronization software, fax programs, third-party add-ins, and most prominent on the list, Microsoft's own Office Suite. In other words, if you bought Office for its seamless integration with sibling components, you are in for some surprises. For example:
Some users report Word's Mail Merge feature is completely incapacitated with the patch installed, yet a Mail Merge instituted from Outlook works fine. Others report being prompted with the dialog shown in Figure 1 for every merge record. In our trials, Word completed a Mail Merge without any intervention, but keep in mind that your experience may vary considerably. For example, if you are running a large mail merge on an older system and you've given free reign to Outlook's Address Book for the maximum 10 minutes, your patience will be tested.
The Object Model Guard breaks Word's document routing function. It no longer works, period. If you rely on Word's routing features to automate work flow, this is "Very Ungood," indeed.
-
Tests using the File->Send To->Mail Recipient under Word worked without a hitch. No warning dialogs. The same action under Excel displayed the dialog shown in Figure 1. Once. All subsequent attempts sent the document without intervention.
In other scenarios, primarily when the application trying to access the Address Book is unknown to Outlook, you might see a warning dialog similar to this:
A program is trying to automatically send email on your behalf. Do you want to allow this? If this is unexpected, it may be a virus and you should choose No.
Unfortunately, this type of dialog gives you no clue as to which application is trying to wrest control of the Address Book. It may or may not be obvious which application is generating this warning. Knowledge is an invaluable tool in the fight against potential viral intrusions to your system, and once again Microsoft has dropped the ball by not providing the proper detail to make an informed decision.
If you synchronize your Palm with Outlook expect to be frisked by the Object Model Guard every time. Other PDA's (personal digital assistants) are thwarted in various ways according to the transport they use to "talk" to Outlook. Here's a partial list of what to expect from the common handheld brands, with information I gathered from newsgroup postings and user feedback:
Windows CE Devices (using ActiveSync Technology)
- Meetings (Outlook Object Model): dialog presented
- Contacts, Notes, Inbox, and so on. (Extended MAPI): no dialog
Palms (dependent on the synchronization software used)
- Chapura PocketMirror (Outlook Object Model): dialog presented
- Palm Pilot Sync (Simple MAPI): dialog presented
- Intellisync by Puma Technology (Extended MAPI): no dialog
Rex devices
- TrueSync (Outlook Object Model): dialog presented
Blackberry
- Rim (Extended MAPI): no dialog
While there has been outcry from the PDA community that Microsoft designed the patch specifically to sync to CE devices without user intervention, this is not technically accurate. It is the use of Extended MAPI protocol that allows a device to sync without prompts. Any program using Simple MAPI or the Outlook Object Model will wake the Object Model Guard.
Which brings us to the reason the Object Model Guard is such a contentious issue, especially in the developer community. There are numerous ways to programmatically hook into Outlook--Simple MAPI, Extended MAPI, the Outlook Object Model, and CDO (Component Data Objects). The Object Model Guard, depending on the method used, has hobbled many an application's ability to access Outlook and left some flat-out broken.
The list of programs affected by the security update is under constant revision. The best advice I can offer is if you use a third-party product in conjunction with Outlook, contact the product vendor before you apply the update. There is also a list available from Slipstick Systems that is routinely updated.
Security Zones
The third and final component of the patch is a configuration change to Outlook's Security Zone settings (Tools->Options->Security tab). Prior to Outlook SR-1, the default Zone setting was "Internet;" applying the update changes the setting to "Restricted sites." Briefly, here is how Security Zones work:
There are four zones: Internet, Local intranet, Trusted sites, and Restricted sites. You can change the security level by selecting a zone and moving the slider (except Restricted sites, which is a custom level). There are four predefined levels: Low, Medium-low, Medium, and High. The text beside the slider displays a brief summary of the type of security applied for each level (see Figure 2). Changing a security level for a zone affects all sites assigned to it.
Figure 2: Outlook's Security Zones dialog
To view exactly which items or behaviors are allowed/denied for each security level; select a zone, choose a slider position, and click the Custom Level button. The settings shown on the resulting dialog are the defaults for that combination. Changing any of these defaults creates a custom security level applicable to all sites within that zone.
Now that I've examined all the rocks, let's put them in the jar. Outlook restricts the content a message displays (or, in the context of a script, what a message can do) by examining what domain it originated from and how your security settings are configured. For example, the settings for a message exchanged on a local intranet are typically set low, so if Mary from the next office sends you an email containing an ActiveX script, it will function. The same is true for Trusted sites, depending on the security level settings. The Restricted sites zone disables almost all options by default. The Internet zone is the fall-through; any site not listed in any of the previous three zones falls under the jurisdiction of Internet zone. This is why you can't specify individual sites for this zone. It is the last line of defense and acts on any domain not explicitly listed in the other zones.
Outlook allows you to set the default Security Zone (from the initialTools->Options->Security tab) to one of two settings: Internet or Restrictedsites. Note the use of the word "default" in the previous sentence. By changing the default Security Zone, you change the default fall-through zone. Prior to the Outlook SR-1 patch, this was the Internet zone. With the patch applied, it becomes Restricted sites.
In other words, if you had somedomain.com listed under Trusted sites, and bob@somedomain.com sent you a message containing a script; even with your default zone set to Restricted sites and all scripting disabled for this zone, the script in the message would still run if you invoked it. So the patch will not protect you from virus-infected email received via the Restricted sites zone.
Got all that? Good, because there's one more layer of complexity involved here. Does all this zone stuff sound familiar? It should if you use Internet Explorer because Microsoft's browser also uses zones (Tools->Internet Options->Security tab). As a matter of fact, both products draw from a common pool of zone settings. Sort of. Add a site to the Local, Trusted, or Restricted zone from IE (5.x) and this information is used by Outlook. The inverse also holds true: Add a site to one of these three zones from Outlook, and IE uses this information to discern what it can and cannot display. Change the security settings for your Internet zone in Outlook, and those options apply to pages viewed with IE.
Now here's where the "Sort of" comes in. The default zone setting for Outlook and IE remain discrete. So you can have IE set to use the Internet zone as a default, and Outlook set to Restricted, and each program will maintain their respective settings.
Of course, none of this matters a nit if you only send plain text messages. Only the HTML format can contain ActiveX scripts and plug-ins.
Don't miss Part 4 of Tom Syroid's series, "Beware the Briar Patch."
In Part 4, Tom covers "Uninstalling the Update" and offers his "Conclusions and Recommendations."
Tom Syroid lives in Saskatoon, Canada, and spends his days working as a systems consultant and freelance writer.
