The Microsoft Office applications (Word, Excel, PowerPoint, etc) have built-in ActiveX control support. ActiveX support allows a richer experience when interacting with an Office document. For example, a document author could use the Safe-For-Initialization Office Web Components (OWC) ActiveX control to retrieve data from an intranet data source.
Office applications’ prompting behavior
By default, Office applications do not prompt when instantiating a Safe-For-Initialization ActiveX control. This is similar to Internet Explorer’s behavior in the Internet Zone. The main difference between Office and IE is that Office applications such as Word, Excel, or PowerPoint do not care about the ActiveX Safe-For-Scripting setting because they do not have any scripting support besides VBA. If you have malicious VBA code running, you are in big trouble even without using any ActiveX controls.
Also by default, ActiveX controls not marked as SFI can only be loaded if the user enables it via the prompt. Here is what the prompt looks like:
How can an attacker abuse this rich experience enabled by Safe-For-Initialization ActiveX controls?
Attackers have discovered ActiveX support in Office applications and have been using it to more effectively lure victims to web-based malware. They have recently used the “Microsoft Scriptlet Component” to navigate victims to a website exploiting a patched Internet Explorer vulnerability (CVE 2009-0075, fixed by security bulletin MS09-002). Seems like attackers have discovered it is easier to trick a user to open a Word document attached to email compared to luring a user to click a dubious-looking link. This specific attack is mentioned in a Trend Malware Blog posting last week (http://blog.trendmicro.com/another-exploit-targets-ie7-bug//).
Let’s take a closer look at this Scriptlet ActiveX control:
Clsid: {ae24fdae-03c6-11d1-8b76-0080c744f389}
Progid: ScriptBridge.ScriptBridge.1
Binary Path: C:\Windows\system32\mshtml.dll
Implements IObjectSafety: True
Safe For Initialization (IObjectSafety): True **
Safe For Scripting (IObjectSafety): True
Safe For Initialization (Registry): False
Safe For Scripting (Registry): False
KillBitted: False
Because this ActiveX control is marked as SFI, an Office document can use it without showing any prompt, similar to what IE does by default in Internet Zone. This is the “by design” behavior. (We explain how you can get this information about any ActiveX control registered on your system in this SRD blog post from Feb 2008.)
How to configure ActiveX support in Office
If you are concerned about Safe-for-Initialization ActiveX controls being instantiated by Office without prompt, you can configure this behavior in Office 2007. Here is a screenshot from the Office 2007 Trust Center:
Office’s help Topic “Enable or disable ActiveX controls in Office documents“ gives a detail explanation about ActiveX configuration. It describes the default “Prompt me before enabling all controls with minimal restrictions” to be the settings described above:
- If the document contains VBA, all ActiveX controls are disabled by default. Office would prompt the user, asking if he/she wants to enable the Active control.
- If the document contains no VBA
-
- ActiveX controls marked as SFI (Safe for initialization) would be loaded without any prompt.
- ActiveX controls not marked as SFI can only be loaded if the user enables it via the prompt.
-
- Office honors the IE’s Killbit setting. If an ActiveX control has been kill-bitted, it will not be loaded.
If you do not want any ActiveX controls to be used by Office documents, you could change the setting to be “Disable all controls without notification”. The ActiveX setting in the trust center can also be set via group policy or registry. For more information, please refer to the following links:
Office 2007: “Security policies and settings in the 2007 Office system”
Office 2003/XP: “How Policies Work” and Microsoft Knowledge Base article 827742.
Chengyun, MSRC Engineering
*Postings are provided “AS IS” with no warranties, and confers no rights.*