Sitelocking ActiveX Controls for the Web

by

c-q-r

eVision, March 7th 2010

Foreword

The following content assumes a basic knowledge of COM components, some proficiency in C++

development and an intermediate level of understanding of security concepts.

Introduction

Sifting through a pile of articles on ActiveX security led me through mazes of abominable sizes. I

emerged with this basic premise: ActiveX controls, especially those provided as part of web applications,

are risky business. To really assess the trouble, however, we need to step through these mazes together.

Let us begin at the door-step of Microsoft:

A Microsoft® ActiveX® control is a COM object that supports the IUnknown interface, and is self-

registering. Many ActiveX controls, particularly those used in Web pages, support the IDispatch

interface, which allows scripting languages, such as Microsoft JScript® development system (JScript)

and Microsoft Visual Basic® Scripting Edition (VBScript) to access the control easily. (5)

So what are COM objects? Let’s break that down: Component Object Model objects. COM objects are a

way to allow for modularization and reuse of software parts, just like in other engineering fields where

you have small parts that could be plugged-in or replaced.(9)

From the above excerpt we understand that ActiveX controls can possibly interact with the container

that they run in. This happens through the interface that the control exposes for use by the container

(for a containing Webpage to interact with your ActiveX control, you implement the IDispatch Interface

for the control describing the methods and properties it exposes). In addition to declaring what they

can do, COM objects are expected to register themselves by adding their GUID to the system registry.

What then is the danger of ActiveX controls? Well, to begin with, they run natively on the machine,

meaning they are not bound by a Virtual Machine or a sandboxing environment (unless a platform is

specifically targeted). Apart from the usual client-side attack that is expected with most applications,

repurposing by the container is another security aspect that must be taken in to account. Repurposing

involves a website exploiting a faulty ActiveX control that is already installed (trusted) and running on

the client machine to attack the client.

To cater for this possibility, Microsoft provides a safety mechanism for any ActiveX control that is meant

to run on the web. The mechanism ensures nothing in-and-of-itself of course, but it does bring up the

issue of security. Any ActiveX control hoping to be loaded by Internet Explorer is required to indicate

whether it is safe to run on the web or not. This is done by allowing ActiveX controls to indicate two

types of safety parameters: Initialization and Scripting.

Initialization and Scripting Safety

Initialization safety means that if the control declares itself Safe for Initialization, IE will allow a

webpage (the webpage containing and invoking the control) to provide initialization data for the control

through the DATA attribute or the PARAM tag.

<object ID=MyObj

classid="clsid:12345678-1234-1234-5678-ABCDEF012345"

width=50 height=50 data="http://www.acme.com/ole/clock.stm">

<param name="CustomProperty1" value="Attacker's Data">

<param name="CustomProperty2" value="Untrusted Input">

</object>

Of course if you are going to indicate that your control is safe for Initialization (we’ll see how to do that

later), you have to be really sure that it truly is safe for your control to handle tainted or malicious data

handed to it by the website. Meaning, you must consider initialization as a possible entry-point to your

control and accordingly validate data obtained in this manner. For example, you should ensure that your

control does not mishandle data by writing them to a constant sized buffer without checking the buffer

size (buffer overflow).

Scripting safety means that IE will allow any script on any webpage hosting your control to interact with

your control. This interaction includes firing methods that are exposed by your control and manipulating

the parameters at will. Again, as with Initialization, your control indicates whether this is safe behavior.

If your control indicates that it is Safe for Scripting, then it had better be ready to handle malicious

scripts trying to exploit its presence on a user machine. This means that methods exposed by your

control need to be scrutinized closely for possible abuse cases.

<object ID=MyObj

classid="clsid:12345678-1234-1234-5678-ABCDEF012345"

width=50 height=50>

<script>

//Calling Methods

MyObj.MethodName("Parameter1", 7);

//Getting and setting properties

alert(MyObj.Property1);

MyObj.Property2 = "NewPropertyValue";

</script>

The code above shows how the script on the page can interact with the object instance of your control.

So, should you indicate that your control is safe?

Well it goes back to what your control needs to accomplish. If it is absolutely necessary for it to interact

with the container page, then you will need to declare and ensure safety. In my opinion, if your control

can do without interacting with the container then it is best not to allow any such interaction from a

defense-in-depth perspective. (In fact, if your website can do without the ActiveX control altogether

then that’s a bucket-worth of troubles that you could spare yourself).

Should your control require interaction with the container, then a critical review of the security of your

exposed methods is in order. Furthermore, any unnecessary interaction should not be made possible,

meaning, you should keep the scope of your IDispatch implementation as narrow as possible for the

desired functionality to be available and nothing more. You should enumerate all possible entry points

to your control and assess the abuses possible from those directions.

Additionally, you should make use of the Site-lock template made available by Microsoft (10). The

Sitelock template allows the control to query its container and find out where the host webpage

originated from, if the webpage came from a domain other than those the control is expected to run

from, the control will block Initialization and Scripting through the SetInterfaceSafetyOptions() method

implemented as part of the template.

Finally, as with any application, privileges required to run your code should be the minimum a system

can afford so that your application is not blocked by the operating system from doing anything the OS

perceives as illegal in the context of the executing process running your control. For instance in Vista,

Internet Explorer runs with user permissions, if the control running in Internet Explorer tries to write to

a system folder, it will be blocked on the OS layer (reference monitor) and your control will not

complete its operation.

How to make your control safe

So assuming that you’ve done your homework and defensively coded your application such that any

untrusted data or untrusted callers are dealt with appropriately, let’s see how you would indicate this to

IE.

There are two methods of indicating safety to IE. You could either use the Component Categories

Manager to create registry entries that identify the safety of your control, or, you could implement the

IObjectSafety Interface in your control. (3)

Component Categories Manager

With this method you implement the registration/deregistration procedures in the DllRegisterServer()

and DllUnregisterServer() functions. To register as safe for either scripting or initialization your code

should add a standard set of keys (also specified elsewhere by the system) in the registry key

“HKEY_CLASSES_ROOT\CLSID\{your-control-GUID}\Implemented Categories\” of your control (see fig 1).

The standard set of categories is defined under HKEY_CLASSES_ROOT\Component

Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4} and HKEY_CLASSES_ROOT\Component

Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}.

Fig 1. Implemented Categories for the Tabular Data Control (just an example)

Fig 2. Standard system component categories

The exact code for doing this can be copied out of the reference article from Microsoft (3).

IObjectSaftey Method

This method, though it seems more complicated, provides you with better “control” of your control’s

behavior. To define safety here, we use two constant bit flags defined in Objsafe.h,

INTERFACESAFE_FOR_UNTRUSTED_DATA and INTERFACESAFE_FOR_UNTRUSTED_CALLER, and

implement the GetInterfaceSafetyOptions and SetInterfaceSafetyOptions methods.

GetInterfaceSafetyOptions retrieves the default capabilities of the control. SetInterfaceSafetyOptions

configures the control, if possible, for safety. The container then used the return value of the

SetInterfaceSafetyOptions to decide on how to behave.

As attested to by the Microsoft (3) and from experimentation with a debugger (12), IE as a container

does not really utilize the GetInterfaceSafetyOptions. (Though this is not documented anywhere, I’ve

found while attaching to an ActiveX process that IE will call GetInterfaceSafetyOptions on scripting

requests from the containing webpage and then follow that up with a call to SetInterfaceSafetyOptions).

Generally, IE calls the SetInterfaceSafetyOptions method whenever it is at a scripting/initialization

junction. If a script on the containing webpage tries to access your ActiveX object, IE calls

SetInterfaceSafetyOptions and depending on the return from that function, E_FAIL or S_OK, IE blocks or

allows the operation. The same thing happens when the container webpage tries to initialize your

control.

The SiteLock template mentioned earlier uses the IObjectSafety method to allow you to control the

safety parameters of your control depending upon the domain from which your control is being loaded.

ActiveX Control Download and Installation

Before we delve into the SiteLock template, we need to briefly discuss signed and unsigned controls. By

default IE 8 is set not to allow unsigned controls to download and install.

Fig 3. Disabled Unsigned Control Download

To change this setting (and I don’t think you should do this unless you’re testing and remember to

change it back), take a look in IE at Tools-> Internet Options -> Security -> Custom Level. There you can

set the option “Initialize and Script ActiveX controls not marked safe for scripting” to “prompt”. Having

changed this setting you will get the warning below in figure 4 instead of the one shown in figure 3.

Now, IE simply informs you of what control the website is trying download and install on your machine

and the publisher/vendor of the ActiveX control.

Fig 4. Install Warning

Should you need to do this during testing, to remove an ActiveX control from your machine ( installed by

IE 8 on an XP SP3 machine), you can do so by browsing to you C:\Windows\Downloaded Program Files\

folder, Right-Clicking on the control and selecting Remove.

Figure 5. Removing an ActiveX control installed by IE.

Signed and Unsigned

To sign a control you will need a public/private key-pair certified by one of the big certificate authorities

out there (13). Thawte (http://www.thawte.com/) seems to be well received by many people in the

field. Signing is done on the CAB file that you generate for you control. The CAB file is how your website

packages and distributes the ActiveX control. To create a CAB file you will need a companion INF file

with your OCX file. You will then feed these files to the cabarc tool found in the Microsoft Cabinet

Software Development Kit (http://support.microsoft.com/kb/310618). Details on how to do this are

found in the CodeProject mentioned in the next section (8).

The SiteLock Template

To really understand security with any system, one must experience that system and be familiar with its

ins-and-outs. I started exploring ActiveX controls through an online article on CodeProject titled “A

Complete ActiveX Example” (8). The example walks you through creating an MFC-based ActiveX control

and using it on a webpage. The article describes the different classes that need to be built and uses a lot

of the code generation capabilities provided by Microsoft Visual Studio to create the ActiveX control.

Once I had my ActiveX control I began looking into how I would integrate it with the SiteLock template.

The sitelock documentation (found in the install folder) describes two methods of implementing safety;

one involves inheriting from the IOleObject and the other from the IObjectWithSite, exclusively. Taking

the seemingly simple route and implementing IObjectWithSite didn’t bear fruit for me. After searching

high and low I discovered that the sitelock template provided by Microsoft addresses ATL-based ActiveX

controls. Further searching directed me to a CodeGuru thread, “ActiveX and

IObjectSafetySiteLock,IObjectWithSite” (11), that shed light on my problem.

MFC ActiveX controls inherit from the COleControl class which essentially exposes the IOleObject

interface. Remember the sitelock documentations mentions that you should either implement

IOleObject or IObjectWithSite, exclusively. My code in this instance had implemented both interfaces.

Unfortunately when you implement both interfaces, the methods implemented for IObjectWithSite are

ignored and precedence goes to the IOleObject interface which in my case did nothing. Thus, if you are

using MFC-based ActiveX controls, you are automatically forced down the route of implementing the

IOleObject interface and not the IObjectWithSite one. Following CodeGuru advice to get passed this I

eventually got things working with the MFC-based ActiveX control.

You will need to download the modified version of Sitelock.h that the commentators provide in their

thread. Next, you will need to change your control’s <control-name>ctrl.h and <control-name>ctrl.cpp

files to implement the IObjectSafetySiteLock Interface methods. You may receive a few compiler errors

and will most likely need to add a DECLARE_INTERFACE_MAP() in your <control-name>ctrl.h file.

Additionally, you must declare the type of safety you think your control affords, for example:

DWORD C<control-name>Ctrl::XObjSafe::dwSupportedSafety = INTERFACESAFE_FOR_UNTRUSTED_CALLER;

Testing my ActiveX control, I found the code either locking all sites out or allowing all sites the same

level of safety. To fix this I had to change the GetInterfaceSafetyOptions function to specify that sites not

on the approved list do not get the safety support indicated by dwSupportedSafety.

Fig 6. Patch to GetInterfaceSafetyOptions

With the above change in the code, IE will only apply your safety settings when the container webpage

is coming from a domain specified in your approved list. On all other pages coming from domains

outside your approved list, IE will not allow the ActiveX to load/script/initialize (IE 8 loads but blocks

operations, IE 6 disallows the loading). This means that if an illegitimate site tries to invoke your ActiveX

control, IE will block it. Also, if an approved site tries to do something that is not indicated as “safe”,

(that is, you have not set the dwSupportedSafety to INTERFACESAFE_FOR_UNTRUSTED_CALLER or

INTERFACESAFE_FOR_UNTRUSTED_CALLER), the respective activity will be blocked.

To better demonstrate this, I will step through an example. The following is the approved list identified

in my code:

The list thus “Allows” the 192.168.1.75 and localhost domains to interact with the control.

The above variable indicates that my control is safe for scripting and that IE should allow it to interact

with scripts on approved sites.

Loading a sample page that tests both scripting and initialization with the control from the legitimate

site we see the following:

Fig 7. PARAM initialization of an ActiveX Control

Notice that the webpage attempts to pass PARAM values to the ActiveX object through the Object tag.

The “Blocked” message indicates that IE blocked this action since in my code I only specified “scripting”

as safe.

What happens when the webpage tries to script the control? Let’s see:

Fig 8. Script interacting with ActiveX object

The webpage contains Javascript that interacts with the MyActiveX1 object setting the InputParameter

Property and invoking the LoadParameter() function. This happens when the submit button on a form

on the webpage is clicked:

Fig 9. Form

The LoadParameter code merely copies the input back out to the output.

The control then fires an event that is caught by another script on the page that writes it out to the

client:

So if we type “cool” in the form field on the webpage and hit submit, this is what we get:

Fig 10. Script handling ActiveX event

Fig 11. Result page of displaying output from ActiveX object

Thus, IE allowed the script to run and interact with the ActiveX control. This makes sense since the

domain the page is running from is approved and the safety flag indicates scripting is allowed in this

context.

What about if we run from another domain? I changed the IP address on the virtual machine I was using

to 192.168.1.38, loaded the page and submitted the form again.

Fig 12. Blocked access to control from illegitimate website

Notice how an error is reported and the activity is blocked. This is because the control does not include

the invoking domain in its list of approved domains. * Without the proposed patch I mentioned earlier in

GetInterfaceSafetyOptions, IE would not have blocked the scripting (it would have applied the same

safety settings to both approved and unapproved sites. This bug appears to exist also in the original

Microsoft sitelock.h code).

A final note on Site-locking: it is stated that if a website from an approved domain (which uses your

ActiveX control) is in any way vulnerable (say you have a Cross-Site-Scripting Vulnerability) then all bets

are off since the attacker can then utilize the legitimate domain’s website to attack users. The argument

for site-locking is defense-in-depth and not the fact that it might be the illusive silver armor/bullet.

Conclusion

This article has focused mainly on using the sitelock template to provide an added layer of security to

the use of ActiveX controls on the web. Since not all ActiveX controls need to interact with the

container, it is important to state this explicitly in the control’s code so that processes that load that

control are notified of permissible interactions with the control. The loading process in the example

discussed in this article was Internet Explorer. The ActiveX control in our example notified IE that it was

safe for scripting but not for Initialization. Accordingly, IE blocked initialization attempts to the control

from websites. The Sitelock template was then used to help further granularize safety-specification

making it specific to an approved list of domains from which the control can be loaded. An experiment

was set up to test interaction with the control from an approved domain and then from an unapproved

domain (ip address).

Having focused much of my attention on basic security concepts of ActiveX development I would like to

note here what has yet to be discussed and is likely to be the topic of future articles. COM components

are a novel idea for software re-use and have been very lightly discussed in this article, further

discussion is warranted in describing the COM framework and how COM components fit in to the bigger

picture of software development. Operating System interlocks on a deeper layer provide the possibility

of setting permissions for COM objects using the dcomcnfg.exe tool. It is important to understand how

the Operating System can be configured to place restrictions on the capabilities of COM components on

the user system. Finally, Zone-locking deserves some exploration with respect to how they can further

increase the general security of an ActiveX control.

You may find the example code I worked up here.

This document should be obtainable from the following links:

http://www.evision.ws/ActiveXTest.pdf

http://securedevelopment.blogspot.com/2010/03/sitelocking-activex-controls-for-

web.html

References

1. Designing Secure ActiveX controls (http://msdn.microsoft.com/en-

us/library/aa752035(VS.85).aspx)

2. Introduction to ActiveX controls (http://msdn.microsoft.com/en-

us/library/aa751972(VS.85,lightweight).aspx#Overview)

3. Safe Initialization and Scripting for ActiveX controls (http://msdn.microsoft.com/en-

us/library/aa751977(VS.85,loband).aspx)

4. ActiveX Security: Improvements and Best Practices (http://msdn.microsoft.com/en-

us/library/bb250471(VS.85,lightweight).aspx)

5. Developing Secure ActiveX controls (http://msdn.microsoft.com/en-us/library/ms885903.aspx)

6. How to tell if ActiveX vulnerabilities are exploitable in Internet Explorer

(http://blogs.technet.com/srd/archive/2008/02/03/activex-controls.aspx)

7. (Kill-Bitting) How to stop an ActiveX control from running in Internet Explorer

http://support.microsoft.com/kb/240797

8. CodeProject: A Complete ActiveX example

(http://www.codeproject.com/KB/COM/CompleteActiveX.aspx)

9. Hunting Security Bugs

10. SiteLock (A Safe-for-Scripting Template) (http://msdn.microsoft.com/en-

us/library/42a01w2f(VS.71).aspx)

11. CodeGuru thread: ActiveX and IObjectSafetySiteLock,IObjectWithSite

http://www.codeguru.com/forum/showthread.php?t=463703

12. Debugging ActiveX controls: (http://msdn.microsoft.com/en-us/library/w54zfak1(VS.71).aspx)

13. Introduction to Code Signing: (http://msdn.microsoft.com/en-

us/library/ms537361(VS.85).aspx#Ensuring_Integrity_a)