DCOM Security Enhancements In Windows Server 2003

What does DCOM do?
The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating
binary softwarecomponents that can interact.The Distributed Component Object Model (DCOM) allows applications to be
distributed across locations that makethe most senseto you and to theapplication.The DCOM wire protocol transparently
provides support for reliable, secure,and efficient communication between COM components.For moreinformation, see
“Component Object Model” on the Microsoft Web siteat http://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 notapply to you.
This featureapplies to you if you havea COM server application that meets one of thefollowing criteria:
Theaccess permission for theapplication is less stringent than thelaunch permission that is necessary to run the
application.
Theapplication is usually activated by a remote COM client without using an administrativeaccount.
Theapplication is only meant to be used locally.This means you can restrictyour 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 madein COM to providecomputerwideaccess controls that govern access to all call,activation, or launch
requests on thecomputer.Thesimplest way to think about theseaccess controls is as an additional AccessCheck call that is
doneagainsta computerwideaccess control list (ACL) on each call,activation, or launch of any COM server on thecomputer. If
the AccessCheck fails, thecall,activation, or launch request will be denied. (This is in addition to any AccessCheck that is run
against theserver-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to access any
COM server on thecomputer.There will bea computerwide ACL for launch permissions to cover activateand launch rights,
and a computerwide ACL for access permissions to cover call rights.Thesecan beconfigured through the ComponentServices
Microsoft Management Console(MMC).
Thesecomputerwide ACLs providea way to override weak security settings specified by a specificapplication through
CoInitializeSecurity or application-specific security settings.This provides a minimum security standard that must be passed,
regardless of thesettings of thespecific server.
These ACLs arechecked when theinterfaces exposed by RPCSS areaccessed.This provides a method to control who has
access to this system service.
These ACLs providea centralized location wherean administrator can set general authorization policy thatapplies to all COM
servers on thecomputer.
By default,Windows Server 2003 SP1 computer restriction settings areas follows.
DCOM Computer Restriction Settings
Permission Administrator Distributed COM Users (Built-in Group)Everyone Anonymous
Launch Local Launch
Local Activation
RemoteLaunch
Remote Activation
Local Launch
Local Activation
RemoteLaunch
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 expeditethe process
of adding users to the DCOM computer restriction settings.
Why is this change important?
Many COM applications includesomesecurity-specific code(for example,calling CoInitializeSecurity), but use weak settings,
often allowing unauthenticated access to the process.Thereis currently no way for an administrator to overridethesesettings
to forcestronger security in earlier versions of Windows.
COM infrastructureincludes the RPCSS,a system servicethat runs during system startup and always runs after that. It
manages activation of COM objects and therunning object tableand provides helper services to DCOM remoting. Itexposes
RPC interfaces that can becalled remotely. Becausesome COM servers allow unauthenticated remoteaccess (as explained in
the previous section), theseinterfaces can becalled 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 theexposurelevel of the COM servers on
a computer. An administrator could getan idea of theexposurelevel by systematically checking theconfigured security
settings for all theregistered COM applications on thecomputer, but, given that thereareabout 150 COM servers in a default
installation of Windows, that task was daunting.There was no way to view thesettings for a server that incorporates security in
thesoftware, short of reviewing thesourcecodefor that software.
DCOM computerwiderestrictions mitigatethesethree problems.They also givean administrator thecapability to disable
incoming DCOM activation, launch,and access calls.
What works differently?
By default, theEveryone group is granted local launch, local activation,and local access permissions.This should enableall
local scenarios to work without modification to thesoftware or the operating system.
By default, theEveryone and Anonymous groups are granted remoteaccess permissions.This enables most COM client
scenarios, including thecommon case wherea COM client passes a local referenceto a remoteserver, in effect turning the
client into a server.
Also by default, only members of the Administrators group are granted remoteactivation and launch permissions.This
disables remoteactivations by non-administrators to installed COM servers.
How do I resolve these issues?
If you implementa COM server and expect to support remoteactivation by a non-administrative COM client or remote
unauthenticated calls, then you should consider whether therisk associated with enabling this process is acceptable or if you
should modify your implementation to not requireremoteactivation by a non-administrative COM client.
If therisk is acceptableand you want to enableremoteactivation by a non-administrative COM client,you will need to change
the default configuration for this feature.
You can changetheconfiguration settings using either the ComponentServices Microsoft Management Console(MMC) or the
Windows registry.
If you usethe ComponentServices MMC snap-in, thesesettings can beconfigured on the COM Security tab of the Properties
dialog box for thecomputer you are managing.The COM Security tab has been modified to enableyou to set computerwide
limits in addition to thestandard default settings for COM servers. Additionally,you can provideseparate ACL settings for local
and remoteaccess under both limits and defaults.
Alternatively,you can configurethese ACL settings using theregistry.
These ACLs arestored in theregistry at thefollowing locations:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction= ACL
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineLaunchRestriction= ACL
Theseare named values of the REG_BINARY typethat contain data describing the ACL of the principals that can access any
COM class or COM object on thecomputer.Theaccess 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 becreated using normal security functions.
Note
COM_RIGHTS_EXECUTE rights mustalways be present;absence of this right will generatean invalid security descriptor. Only
users with Administrator rights can modify thesesettings.
What existing functionality is changing in Windows Server 2003 Service Pack 1?
RPCSS runs as a network service
Detailed description
RPCSS is a key servicefor the RPC Endpoint Mapper and DCOM infrastructurethat is network facing.This serviceran as Local
System in previous versions of Windows.To reducetheattack surface of Windows and provide defensein depth, the RPCSS
servicefunctionality was split into two services.The RPCSS service with all the original functionality that did not requireLocal
System privileges now runs under the Network Serviceaccount. A new DCOMLaunch servicethat includes functionality that
requires Local System privileges runs under theLocal System account; however, this serviceis not network facing.
Why is this change important?
This changereduces theattack surfaceand provides defensein depth for the RPCSS service becausean elevation of privilege
in the RPCSS service will now belimited to the Network Service privilege.
What works differently?
This changeshould betransparent to users becausethecombination 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 havetwo types of permissions: launch permissions and access permissions.Launch permissions
control authorization to starta COM server during COM activation if theserver is notalready running.These permissions are
defined as security descriptors thatarespecified in registry settings. Access permissions control authorization to call a running
COM server.These permissions are defined as security descriptors provided to the COM infrastructurethrough 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 thecaller is local to theserver or remote.
Thefirst change distinguishes the COM access rights, based on distance.Thetwo distances thatare defined areLocal and
Remote. A Local COM messagearrives by way of theLightweight Remote Procedure Call (LRPC) protocol, whilea Remote
COM messagearrives by way of a remote procedurecall (RPC) host protocol liketransmission control protocol (TCP).
COM activation is theact of getting a COM interface proxy on a client by calling CoCreateInstance or one of its variants. As a
sideeffect of this activation process, sometimes a COM server must bestarted to satisfy theclient’s request. A launch
permissions ACL asserts who is allowed to starta COM server. An access permissions ACL asserts who is allowed to activatea
COM object or call that objectafter the COM server is already running.
Thesecond changeis that thecall and activation rights areseparated to reflect two distinct operations and to movethe
activation right from theaccess permission ACL to thelaunch permission ACL.Sinceactivation and launching are both related
to acquiring an interface pointer,activation and launch access rights logically belong together in one ACL. Becauseyou always
specify launch permissions through configuration (as compared to access permissions, which are often specified
programmatically), putting theactivation rights in thelaunch permission ACL provides theadministrator with control over
activation.
TheLaunch Permission access control entries (ACEs) are broken into four access rights:
Local Launch (LL)
RemoteLaunch (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 theadministrator to apply very specific security configurations.For example,you can configurea COM server so
that itaccepts local calls from everyone, while only accepting remotecalls 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 restrictan application so that it can only be used locally without
exposing theapplication 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 exposeitself to unauthenticated users to implementa COM callback scenario. In this
scenario, theapplication mustalso exposeits activation to unauthenticated users, which might not be desirable because
malicious users could usethat scenario to gain unauthorized access to that server.
Precise COM permissions giveflexibility to theadministrator to control a computer’s COM permission policy.These
permissions enablesecurity for the described scenarios.
What works differently? Are there any dependencies?
To provide backwards compatibility,existing COM security descriptors areinterpreted 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.
Thereare no backwards-compatibility issues for call or launch rights.Thereis, however,an activation rights compatibility issue.
If, in theexisting security descriptors for a COM server, theconfigured launch permissions are morerestrictivethan theaccess
permissions and are morerestrictivethan what is minimally needed for clientactivation scenarios, then theLaunch
Permissions ACL must be modified to givetheauthorized clients theappropriateactivation permissions.
For COM applications that usethe default security settings, thereare no compatibility issues.For applications thatare
dynamically started using COM activation, most will have no compatibility issues, sincethelaunch permissions mustalready
includeanyone who is ableto activatean object. Otherwise, such applications would have generated activation failures even
beforeapplying Service Pack 1, when callers without launch permission try to activatean objectand the COM server is not
already running.
Theapplications of most concern for compatibility issues are COM applications thatarealready started by way of some other
mechanism, such as Windows Explorer or Service Control Manager. You can also start theseapplications by way of a previous
COM activation, which overrides the defaultaccess and launch permissions and specifies launch permissions thatare more
restrictivethan thecall permissions.For more details on addressing this compatibility issue, see”How do I resolvethese
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, remoteaccess, or both, will beinterpreted to allow both local and remote
access. Any ACE that was edited to deny local access, remoteaccess, or both, will beinterpreted to deny both local and remote
access.Whenever you uninstall a service pack,you should ensurethat no newly set ACEs will causeapplications to stop
working.
How do I resolve these issues?
If you implementa COM server and you overridethe default security settings,confirm that theapplication-specific launch
permissions ACL grants activation permission to appropriate users. If it does not,you will need to changeyour applicationspecific
launch permission ACL to giveappropriate users activation rights so applications and Windows components that use
DCOM do not fail.Theseapplication-specific launch permissions arestored in theregistry.
The COM ACLs can becreated or modified using normal security functions.
What settings are added or changed in Windows Server 2003 Service Pack 1?
Caution
Improper use of thesesettings can causeapplications and Windows components that use DCOM to fail.
In thefollowing table, theseabbreviations are used:
LL – Local Launch
LA – Local Activation
RL – RemoteLaunch
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 bethe
effectivevalues.)
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 bethe
effectivevalues.)
Everyone:LC, RC
Anonymous:LC, RC
ACL
CallFailure
LoggingLevel
HKEY_LOCAL_MACHINE
\SOFTWARE \Microsoft
\Ole\
Notapplicable. This registry key is not present; however,a
missing key or valueis interpreted as 2.
This event is not logged by default. If you
changethis valueto 1 to start logging this
information to help you troubleshootan
issue, besureto monitor thesize of your
event log,as this is an event that can
generatea 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\
Notapplicable. This registry key is not present, however a
missing key or valueis 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.
D
C
O
M:M
a
c
hin
e
L
a
u
n
c
h
R
e
s
t
ric
tio
n
s in
S
e
c
u
rit
y
D
e
s
c
rip
t
o
r
D
e
finitio
n
L
a
n
g
u
a
g
e
(
S
D
D
L
)
S
y
n
t
a
x
(
G
r
o
u
p
P
olic
y
o
bj
e
c
t
)
C
o
m
p
u
t
e
r
C
o
n
fig
u
r
a
tio
n
\
Win
d
o
w
s
S
e
t
tin
g
s
\
L
o
c
al P
olicie
s
\
S
e
c
u
rit
y
O
p
tio
n
s
N
o
t
a
p
plic
a
ble. N
o
t
d
e
fin
e
d. A
c
c
e
s
s
C
o
n
t
r
ol Lis
t 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 Notapplicable. Not defined. Control List in SDD
L
F
o
r
m
a
t.E
xis
t
e
n
c
e
o
f
t
his
p
olic
y, o
v
e
r
rid
e
s, values in MachineAccess Restriction,abo