Limiting Component Use

Written by: Christoph Wille
Translated by: Bernhard Spuida
First published: 1/29/2002

Anybody operating more than one site per server - and this concerns not only ISPs - will possibly confront the situation where a component installed on the server is supposed to be accessible by certain Web sites only. The reason for this is that either the customer paying for it is supposed to be the only one to use it (and not by other web sites coincidentally running on the same server) or that certain components are security sensitive (e.g. business logic components).

As always, there are several roads leading towards Rome, but they all have something to do with NT security - the Access Control Lists (ACL). In principle, we simply make sure that only authorized accounts gain access to the data important for the component: on the one hand this is the DLL/EXE in which the component 'resides', on the other hand the information for component instantiation in the registry database.

Securing using NTFS Permissions

The fastest way to achieve this goal is using NTFS permissions on the DLL/EXE of the component. I used AspTear as example component, together with a very minimalistic test script:

<%
Set xObj = Server.CreateObject("SOFTWING.ASPtear")
%>

With a normal call the output of this script is precisely nothing - a blank page. Changing the NTFS Permissions on asptear.dll from Everyone/Full Control (standard setting) to e.g. Administrator and SYSTEM/Full Control yields as a result something looking like this:

Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object
/aspheute/DllCage/doasptear.asp, line 2

Attention ASP and IIS cache the class factories of the components to improve performance. To prevent the side effects resulting from this, always call net stop iisadmin /y followed by net start w3svc after the change.

This radical therapy does not help us at all, as now nobody may access the component anymore. How then can we get the component to run again? Well, as sites usually run pooled (see screenshot),

we have to add Read and Execute for the IWAM_machinename Account:

And presto, our page works again! The catch with that is that it now works for all the sites running pooled - that is, all sites. When we have a new application created by the Internet Services Manager (ISM), it will be entered into Component Services (here the standard pooled application is selected, so that everyone will know where it is to be found):

The last two applications in the list are independent applications, which, just like the pooled application, can be assigned a different account (and should, if we want to be able to distinguish the various sites in this manner):

Therefore we have to take the following into consideration when we want to secure a component by means of NTFS ACLs:

• All sites, that are to use the Component, must run under Pooled/Out-of-process Accounts that are different from those for which this component may not be used.
• The DLL/EXE of the Component must be restricted via NTFS ACL to Read and Execute for the authorized Pooled/Out-of-process accounts.

Securing by means of Registry Permissions

The method presented above only works up to a well defined breaking point: what to do when site A may use component X, site B component Y - and X and Y are stored in one and the same DLL? Sounds abstract? Not at all: Scripting.Dictionary and Scripting.FileSystemObject share a common DLL - and every now and then locking the FileSystemObject for a site can be important.

Now that the problem is known, what are we to do? A component can be instantiated via Server.CreateObject either by means of ProgId (zB Scripting.FileSystemObject) or ClassId (e.g. {A06F79A7-A329-11D2-880F-0020AFD81B6D}). Both are stored in the Registry and tell COM+ how the component is to be loaded (simply put). As the ClassId is the decisive piece of information for COM+ in the end, only this needs to be secured via ACL.

How to do that? First we start regedit.exe and look for the ProgId, which is Scripting.FileSystemObject in our case:

A double-click on (Default) and we can copy the appropriate ClassId from the Edit String dialogbox to the clipboard. Now we start the 'real' Registry Editor regedt32.exe - for only this may be used to set ACLs - the search functions however are, to put it mildly, very limited - this is the reason for the circuitous route via regedit.exe.

We now are in the Registry Editor (regedt32.exe). There we select the window with the HKEY_LOCAL_MACHINE branch of the Registry, and launch the Find Key command in the View menu. Into this we paste the previously copied ClassId and click 'Find Next'. We have the proper hit when the element is preceded by a Plus symbol, may be opened and has a ProgId subkey:

The hard part is done by now - under Security / Permissions we find the ACL dialogbox we are used to. To let a user create a component, he must have Read Access to the ey (and subkeys). The following ACL as an example shows that IWAM_machinename does not have any access whatsoever:

And right, the FileSystemObject is off limits from now on:

Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object
/AspHeute/DllCage/dofso.asp, line 2

Here the same holds true as for NTFS permissions - just admit the users that have been granted the respective COM+ Applications (Web application roots).

Conclusion

With changes to NTFS and Registry permissions, Pandora's Box can be opened! Be careful what you do.

Links

AspTear