DCOM Security Enhancements

Applies To: Windows Server 2003 with SP1

What does DCOM do?

The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. The Distributed Component Object Model (DCOM) allows applications to be distributed across locations that make the most sense to you and to the application. The DCOM wire protocol transparently provides support for reliable, secure, and efficient communication between COM components. For more information, see "Component Object Model" on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=20922.

Who does this feature apply to?

If you only use COM for in-process COM components, this section does not apply to you.

This feature applies to you if you have a COM server application that meets one of the following criteria:

• The access permission for the application is less stringent than the launch permission that is necessary to run the application.

• The application is usually activated by a remote COM client without using an administrative account.

• The application is only meant to be used locally. This means you can restrict your COM server application so it is not remotely accessible.

What new functionality is added to this feature in Windows Server 2003 Service Pack 1?

Computerwide restrictions

Detailed description

A change has been made in COM to provide computerwide access controls that govern access to all call, activation, or launch requests on the computer. The simplest way to think about these access controls is as an additional AccessCheck call that is done against a computerwide access control list (ACL) on each call, activation, or launch of any COM server on the computer. If the AccessCheck fails, the call, activation, or launch request will be denied. (This is in addition to any AccessCheck that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to access any COM server on the computer. There will be a computerwide ACL for launch permissions to cover activate and launch rights, and a computerwide ACL for access permissions to cover call rights. These can be configured through the Component Services Microsoft Management Console (MMC).

These computerwide ACLs provide a way to override weak security settings specified by a specific application through CoInitializeSecurity or application-specific security settings. This provides a minimum security standard that must be passed, regardless of the settings of the specific server.

These ACLs are checked when the interfaces exposed by RPCSS are accessed. This provides a method to control who has access to this system service.

These ACLs provide a centralized location where an administrator can set general authorization policy that applies to all COM servers on the computer.

By default, Windows Server 2003 SP1 computer restriction settings are as follows.

DCOM Computer Restriction Settings

Permission	Administrator	Distributed COM Users (Built-in Group)	Everyone	Anonymous
Launch	Local Launch Local Activation Remote Launch Remote Activation	Local Launch Local Activation Remote Launch Remote Activation	Local Launch Local Activation	N/A
Access	N/A	Local Access Remote Access	Local Access Remote Access	Local Access Remote Access

Note

Distributed COM Users is a new built-in group included with Windows Server 2003 Service Pack 1 to expedite the process of adding users to the DCOM computer restriction settings.

Why is this change important?

Many COM applications include some security-specific code (for example, calling CoInitializeSecurity), but use weak settings, often allowing unauthenticated access to the process. There is currently no way for an administrator to override these settings to force stronger security in earlier versions of Windows.

COM infrastructure includes the RPCSS, a system service that runs during system startup and always runs after that. It manages activation of COM objects and the running object table and provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because some COM servers allow unauthenticated remote access (as explained in the previous section), these interfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users using remote, unauthenticated computers.

In earlier versions of Windows, there was no way for an administrator to understand the exposure level of the COM servers on a computer. An administrator could get an idea of the exposure level by systematically checking the configured security settings for all the registered COM applications on the computer, but, given that there are about 150 COM servers in a default installation of Windows, that task was daunting. There was no way to view the settings for a server that incorporates security in the software, short of reviewing the source code for that software.

DCOM computerwide restrictions mitigate these three problems. They also give an administrator the capability to disable incoming DCOM activation, launch, and access calls.

What works differently?

By default, the Everyone group is granted local launch, local activation, and local access permissions. This should enable all local scenarios to work without modification to the software or the operating system.

By default, the Everyone and Anonymous groups are granted remote access permissions. This enables most COM client scenarios, including the common case where a COM client passes a local reference to a remote server, in effect turning the client into a server.

Also by default, only members of the Administrators group are granted remote activation and launch permissions. This disables remote activations by non-administrators to installed COM servers.

How do I resolve these issues?

If you implement a COM server and expect to support remote activation by a non-administrative COM client or remote unauthenticated calls, then you should consider whether the risk associated with enabling this process is acceptable or if you should modify your implementation to not require remote activation by a non-administrative COM client.

If the risk is acceptable and you want to enable remote activation by a non-administrative COM client, you will need to change the default configuration for this feature.

You can change the configuration settings using either the Component Services Microsoft Management Console (MMC) or the Windows registry.

If you use the Component Services MMC snap-in, these settings can be configured on the COM Security tab of the Properties dialog box for the computer you are managing. The COM Security tab has been modified to enable you to set computerwide limits in addition to the standard default settings for COM servers. Additionally, you can provide separate ACL settings for local and remote access under both limits and defaults.

Alternatively, you can configure these ACL settings using the registry.

These ACLs are stored in the registry at the following locations:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction= ACL
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineLaunchRestriction= ACL

These are named values of the REG_BINARY type that contain data describing the ACL of the principals that can access any COM class or COM object on the computer. The access rights in the ACL are:

COM_RIGHTS_EXECUTE 1
COM_RIGHTS_EXECUTE_LOCAL 2
COM_RIGHTS_EXECUTE_REMOTE 4
COM_RIGHTS_ACTIVATE_LOCAL 8
COM_RIGHTS_ACTIVATE_REMOTE 16

These ACLs can be created using normal security functions.

Note

COM_RIGHTS_EXECUTE rights must always be present; absence of this right will generate an invalid security descriptor. Only users with Administrator rights can modify these settings.

What existing functionality is changing in Windows Server 2003 Service Pack 1?

RPCSS runs as a network service

Detailed description

RPCSS is a key service for the RPC Endpoint Mapper and DCOM infrastructure that is network facing. This service ran as Local System in previous versions of Windows. To reduce the attack surface of Windows and provide defense in depth, the RPCSS service functionality was split into two services. The RPCSS service with all the original functionality that did not require Local System privileges now runs under the Network Service account. A new DCOMLaunch service that includes functionality that requires Local System privileges runs under the Local System account; however, this service is not network facing.

Why is this change important?

This change reduces the attack surface and provides defense in depth for the RPCSS service because an elevation of privilege in the RPCSS service will now be limited to the Network Service privilege.

What works differently?

This change should be transparent to users because the combination of the RPCSS and DCOMLaunch services is equivalent to the previous RPCSS service provided in prior versions of Windows.

More specific COM permissions

Detailed description

COM server applications have two types of permissions: launch permissions and access permissions. Launch permissions control authorization to start a COM server during COM activation if the server is not already running. These permissions are defined as security descriptors that are specified in registry settings. Access permissions control authorization to call a running COM server. These permissions are defined as security descriptors provided to the COM infrastructure through the CoInitializeSecurity API, or using registry settings. Both launch and access permissions allow or deny access based on principals, and make no distinction as to whether the caller is local to the server or remote.

The first change distinguishes the COM access rights, based on distance. The two distances that are defined are Local and Remote. A Local COM message arrives by way of the Lightweight Remote Procedure Call (LRPC) protocol, while a Remote COM message arrives by way of a remote procedure call (RPC) host protocol like transmission control protocol (TCP).

COM activation is the act of getting a COM interface proxy on a client by calling CoCreateInstance or one of its variants. As a side effect of this activation process, sometimes a COM server must be started to satisfy the client’s request. A launch permissions ACL asserts who is allowed to start a COM server. An access permissions ACL asserts who is allowed to activate a COM object or call that object after the COM server is already running.

The second change is that the call and activation rights are separated to reflect two distinct operations and to move the activation right from the access permission ACL to the launch permission ACL. Since activation and launching are both related to acquiring an interface pointer, activation and launch access rights logically belong together in one ACL. Because you always specify launch permissions through configuration (as compared to access permissions, which are often specified programmatically), putting the activation rights in the launch permission ACL provides the administrator with control over activation.

The Launch Permission access control entries (ACEs) are broken into four access rights:

• Local Launch (LL)

• Remote Launch (RL)

• Local Activation (LA)

• Remote Activation (RA)

The Access Permission security descriptor is split into two access rights:

• Local Access calls (LC)

• Remote Access calls (RC)

This allows the administrator to apply very specific security configurations. For example, you can configure a COM server so that it accepts local calls from everyone, while only accepting remote calls from Administrators. These distinctions can be specified through changes to the COM Permissions security descriptors.

Why is this change important? What threats does it help mitigate?

Earlier versions of the COM server application have no way to restrict an application so that it can only be used locally without exposing the application on the network by way of DCOM. When a user has access to a COM server application, he or she has access for both local and remote use.

A COM server application might want to expose itself to unauthenticated users to implement a COM callback scenario. In this scenario, the application must also expose its activation to unauthenticated users, which might not be desirable because malicious users could use that scenario to gain unauthorized access to that server.

Precise COM permissions give flexibility to the administrator to control a computer’s COM permission policy. These permissions enable security for the described scenarios.

What works differently? Are there any dependencies?

To provide backwards compatibility, existing COM security descriptors are interpreted to allow or deny both local and remote access simultaneously. That is, an access control entry will either allow both local and remote, or deny both local and remote.

There are no backwards-compatibility issues for call or launch rights. There is, however, an activation rights compatibility issue. If, in the existing security descriptors for a COM server, the configured launch permissions are more restrictive than the access permissions and are more restrictive than what is minimally needed for client activation scenarios, then the Launch Permissions ACL must be modified to give the authorized clients the appropriate activation permissions.

For COM applications that use the default security settings, there are no compatibility issues. For applications that are dynamically started using COM activation, most will have no compatibility issues, since the launch permissions must already include anyone who is able to activate an object. Otherwise, such applications would have generated activation failures even before applying Service Pack 1, when callers without launch permission try to activate an object and the COM server is not already running.

The applications of most concern for compatibility issues are COM applications that are already started by way of some other mechanism, such as Windows Explorer or Service Control Manager. You can also start these applications by way of a previous COM activation, which overrides the default access and launch permissions and specifies launch permissions that are more restrictive than the call permissions. For more details on addressing this compatibility issue, see "How do I resolve these issues?" in the next section.

If a system that was updated to Windows Server 2003 Service Pack 1 is rolled back to an earlier service pack, any access control entry that was edited to allow local access, remote access, or both, will be interpreted to allow both local and remote access. Any ACE that was edited to deny local access, remote access, or both, will be interpreted to deny both local and remote access. Whenever you uninstall a service pack, you should ensure that no newly set ACEs will cause applications to stop working.

How do I resolve these issues?

If you implement a COM server and you override the default security settings, confirm that the application-specific launch permissions ACL grants activation permission to appropriate users. If it does not, you will need to change your application-specific launch permission ACL to give appropriate users activation rights so applications and Windows components that use DCOM do not fail. These application-specific launch permissions are stored in the registry.

The COM ACLs can be created or modified using normal security functions.

What settings are added or changed in Windows Server 2003 Service Pack 1?

Warning

Improper use of these settings can cause applications and Windows components that use DCOM to fail.

In the following table, these abbreviations are used:

LL - Local Launch

LA - Local Activation

RL - Remote Launch

RA - Remote Activation

LC - Local Access calls

RC - Remote Access calls

DCOM Settings

Setting name	Location	Previous default value	Default value	Possible values
MachineLaunch Restriction	HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft\Ole\	Everyone: LL, LA, RL, RA Anonymous: LL, LA, RL, RA (This is a new registry key. Based on existing behavior, these would be the effective values.)	Administrator: LL, LA, RL, RA Everyone: LL, LA Distributed COM users: LL, LA, RL, RA	ACL
MachineAccess Restriction	HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft\Ole\	Everyone: LC, RC Anonymous: LC, RC (This is a new registry key. Based on existing behavior, these would be the effective values.)	Everyone: LC, RC Anonymous: LC, RC	ACL
CallFailure LoggingLevel	HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Ole\	Not applicable.	This registry key is not present; however, a missing key or value is interpreted as 2. This event is not logged by default. If you change this value to 1 to start logging this information to help you troubleshoot an issue, be sure to monitor the size of your event log, as this is an event that can generate a large number of entries.	1 - Always log event log failures when COM infrastructure finds an invalid security descriptor. 2 - Never log event log failures when COM infrastructure finds an invalid security descriptor.
InvalidSecurity Descriptor LoggingLevel	HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft\Ole\	Not applicable.	This registry key is not present, however a missing key or value is interpreted as 1. This event is logged by default. It should rarely occur.	1 - Always log event log failures when COM infrastructure finds an invalid security descriptor. 2 - Never log event log failures when COM infrastructure finds an invalid security descriptor.
DCOM:Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) Syntax	(Group Policy object) Computer Configuration \Windows Settings \Local Policies \Security Options	Not applicable.	Not defined.	Access Control List in SDDL Format. Existence of this policy, overrides, values in MachineLaunch Restriction, above.
DCOM:Machine Access Restrictions in Security Descriptor Definition Language (SDDL) Syntax	(Group Policy object) Computer Configuration \Windows Settings \Local Policies \Security Options	Not applicable.	Not defined.	Control List in SDDL Format. Existence of this policy, overrides, values in MachineAccess Restriction, above.