DCOM Security Enhancements In Windows Server 2003

IT Support Forum Forums Windows Windows Server 2003 R2 General Discussion DCOM Security Enhancements In Windows Server 2003

This topic contains 0 replies, has 1 voice, and was last updated by  Webmaster 3 months, 1 week ago.

  • Author
    Posts
  • #2191

    Webmaster
    Keymaster

    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

You must be logged in to reply to this topic.