Aprimoramentos de segurança DCOM no Windows XP Service Pack 2 e Windows Server 2003 Service Pack 1

O Windows Server XP Service Pack 2 (SP2) e o Windows Server 2003 Service Pack 1 (SP1) introduzem configurações de segurança padrão aprimoradas para o DCOM (Distributed Component Object Model). Especificamente, eles introduzem direitos mais granulares que permitem que um administrador tenha controle independente sobre permissões locais e remotas para iniciar, ativar e acessar servidores COM.

O que faz o DCOM?

O Microsoft Component Object Model (COM) é um sistema independente de plataforma, distribuído e orientado a objetos para criar componentes de software binários que podem interagir. O DCOM (Distributed Component Object Model) permite que os aplicativos sejam distribuídos entre os locais que fazem mais sentido para você e para o aplicativo. O protocolo de fio DCOM fornece suporte transparente para comunicação confiável, segura e eficiente entre componentes COM.

A quem se aplica este recurso?

Se você usar COM apenas para componentes COM em processo, esse recurso não se aplicará a você.

Esse recurso se aplica a você se você tiver um aplicativo de servidor COM que atenda a um dos seguintes critérios:

• A permissão de acesso para o aplicativo é menos rigorosa do que a permissão de inicialização, que é necessária para executar o aplicativo.
• O aplicativo geralmente é ativado por um cliente COM remoto sem usar uma conta administrativa.
• O aplicativo destina-se a ser usado apenas localmente. Isso significa que você pode restringir seu aplicativo de servidor COM para que ele não seja acessível remotamente.

Que nova funcionalidade é adicionada a esse recurso no Windows XP Service Pack 2 e Windows Server 2003 Service Pack 1?

Restrições em todo o computador

Foi feita uma alteração no COM para fornecer controles de acesso em todo o computador que controlam o acesso a todas as solicitações de chamada, ativação ou inicialização no computador. A maneira mais simples de pensar sobre esses controles de acesso é como uma chamada AccessCheck adicional que é feita em uma lista de controle de acesso (ACL) em todo o computador em cada chamada, ativação ou inicialização de qualquer servidor COM no computador. Se o AccessCheck falhar, a chamada, ativação ou solicitação de inicialização será negada. Isso é adicional a qualquer AccessCheck executado nas ACLs específicas do servidor. Na verdade, ele fornece um padrão de autorização mínimo que deve ser passado para acessar qualquer servidor COM no computador. Há uma ACL em todo o computador para permissões de inicialização para cobrir direitos de ativação e inicialização e uma ACL em todo o computador para permissões de acesso para cobrir direitos de chamada. Eles podem ser configurados por meio do MMC (Console de Gerenciamento Microsoft) dos Serviços de Componentes.

Essas ACLs em todo o computador fornecem uma maneira de substituir configurações de segurança fracas especificadas por um aplicativo específico por meio de CoInitializeSecurity ou configurações de segurança específicas do aplicativo. Isso fornece um padrão de segurança mínimo que deve ser passado, independentemente das configurações do servidor específico.

Essas ACLs são verificadas quando as interfaces expostas pelo RPCSS são acessadas. Isso fornece um método para controlar o acesso a esse serviço do sistema.

Essas ACLs fornecem um local centralizado onde um administrador pode definir a diretiva de autorização geral que se aplica a todos os servidores COM no computador.

Por padrão, as configurações de restrição do computador Windows XP SP2 são:

Por padrão, as configurações de restrição de computador do Windows Server 2003 SP 1 são as seguintes.

Por que essas alterações são importantes? Quais ameaças elas ajudam a minimizar?

Muitos aplicativos COM incluem algum código específico de segurança (por exemplo, chamando CoInitializeSecurity), mas usam configurações fracas, muitas vezes permitindo acesso não autenticado ao processo. No momento, não há como um administrador substituir essas configurações para forçar uma segurança mais forte em versões anteriores do Windows.

A infraestrutura COM inclui o RPCSS, um serviço do sistema que é executado durante a inicialização do sistema e sempre é executado depois disso. Ele gerencia a ativação de objetos COM e a tabela de objetos em execução e fornece serviços auxiliares para comunicação remota DCOM. Ele expõe interfaces RPC que podem ser chamadas remotamente. Como alguns servidores COM permitem acesso remoto não autenticado, essas interfaces podem ser chamadas por qualquer pessoa, incluindo usuários não autenticados. Como resultado, o RPCSS pode ser atacado por usuários mal-intencionados em computadores remotos e não autenticados.

Em versões anteriores do Windows, não havia como um administrador entender o nível de exposição dos servidores COM em um computador. Um administrador teve uma ideia do nível de exposição verificando sistematicamente as configurações de segurança definidas para todos os aplicativos COM registrados no computador, mas, dado que há cerca de 150 servidores COM em uma instalação padrão do Windows, essa tarefa foi assustadora. Não havia como visualizar as configurações de um servidor que incorpora segurança no software, a não ser revisar o código-fonte desse software.

As restrições de todo o computador DCOM atenuam esses três problemas. Ele também dá a um administrador a capacidade de desabilitar a ativação, a inicialização e as chamadas DCOM de entrada.

O que passou a funcionar de maneira diferente?

Por padrão, o grupo Todos recebe permissões de inicialização local, ativação local e chamada de acesso local. Isso permite que todos os cenários locais funcionem sem modificação no software ou no sistema operacional.

Por padrão, no Windows XP SP2, o grupo Todos recebe permissões de chamada de acesso remoto. No Windows Server 2003 SP1, os grupos Todos e Anônimos recebem permissões de acesso remoto. Isso habilita a maioria dos cenários de cliente COM, incluindo o caso comum em que um cliente COM passa uma referência local para um servidor remoto, transformando o cliente em um servidor. No Windows XP SP2, isso pode desabilitar cenários que exigem chamadas de acesso remoto não autenticadas.

Também por padrão, somente os membros do grupo Administradores recebem permissões de ativação e inicialização remotas. Isso desabilita ativações remotas por não administradores para servidores COM instalados.

Como resolvo esses problemas?

Se você implementar um servidor COM e espera oferecer suporte à ativação remota por um cliente COM não administrativo, deverá considerar se o risco associado à habilitação desse processo é aceitável ou se deve modificar sua implementação para não exigir ativação remota por um cliente COM não administrativo ou chamadas remotas não autenticadas.

Se o risco for aceitável e você desejar habilitar a ativação remota por um cliente COM não administrativo ou chamadas remotas não autenticadas, altere a configuração padrão para esse recurso.

Você pode alterar as definições de configuração usando o MMC (Console de Gerenciamento Microsoft) dos Serviços de Componentes ou o Registro do Windows.

Se você usar o snap-in MMC de Serviços de Componentes, essas configurações poderão ser definidas na guia Segurança COM da caixa de diálogo Propriedades do computador que você está gerenciando. A área Permissões de Acesso foi modificada para permitir que você defina limites em todo o computador, além das configurações padrão padrão para servidores COM. Além disso, você pode fornecer configurações de ACL separadas para acesso local e remoto sob limites e padrões.

Na área Permissões de Inicialização e Ativação, você pode controlar as permissões locais e remotas, bem como os limites em todo o computador e os padrões. Você pode especificar a ativação local e remota e iniciar permissões independentemente.

Como alternativa, você pode definir essas configurações de ACL usando o Registro.

Essas ACLs são armazenadas no Registro nos seguintes locais:

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

Esses são valores nomeados do tipo REG_BINARY que contêm dados que descrevem a ACL das entidades de segurança que podem acessar qualquer classe COM ou objeto COM no computador. Os direitos de acesso na ACL são:

COM_RIGHTS_EXECUTE 1
COM_RIGHTS_EXECUTE_LOCAL 2
COM_RIGHTS_EXECUTE_REMOTE 4
COM_RIGHTS_ACTIVATE_LOCAL 8
COM_RIGHTS_ACTIVATE_REMOTE 16

Essas ACLs podem ser criadas usando funções de segurança normais.

Que funcionalidade existente está mudando no Windows XP Service Pack 2 e Windows Server 2003 Service Pack 1?

RPCSS é executado como um serviço de rede

O RPCSS é um serviço chave para o Mapeador de Pontos de Extremidade RPC e a infraestrutura DCOM. Este serviço era executado como Sistema Local em versões anteriores do Windows. Para reduzir a superfície de ataque do Windows e fornecer defesa em profundidade, a funcionalidade de serviço RPCSS foi dividida em dois serviços. O serviço RPCSS com toda a funcionalidade original que não exigia privilégios de Sistema Local agora é executado na conta Serviço de Rede. Um novo serviço DCOMLaunch que inclui funcionalidade que requer privilégios de Sistema Local é executado na conta Sistema Local.

Por que essas alterações são importantes?

Essa alteração reduz a superfície de ataque e fornece defesa em profundidade para o serviço RPCSS porque uma elevação de privilégio no serviço RPCSS agora está limitada ao privilégio Serviço de Rede.

O que passou a funcionar de maneira diferente?

Essa alteração deve ser transparente para os usuários porque a combinação dos serviços RPCSS e DCOMLaunch é equivalente ao serviço RPCSS anterior fornecido em versões anteriores do Windows.

Permissões COM mais específicas

Os aplicativos de servidor COM têm dois tipos de permissões: permissões de inicialização e permissões de acesso. Inicie a autorização de controle de permissões para iniciar um servidor COM durante a ativação COM se o servidor ainda não estiver em execução. Essas permissões são definidas como descritores de segurança especificados nas configurações do Registro. As permissões de acesso controlam a autorização para chamar um servidor COM em execução. Essas permissões são definidas como descritores de segurança fornecidos à infraestrutura COM por meio da API CoInitializeSecurity ou usando configurações do Registro. As permissões de inicialização e acesso permitem ou negam acesso com base em entidades de segurança e não fazem distinção se o chamador é local para o servidor ou remoto.

A primeira alteração distingue os direitos de acesso à OCM, com base na distância. As duas distâncias definidas são Local e Remoto. Uma mensagem COM local chega por meio do protocolo LRPC (Local Remote Procedure Call), enquanto uma mensagem COM remota chega por meio de um protocolo de host RPC (chamada de procedimento remoto), como TCP (transmission control protocol).

A ativação COM é o ato de obter um proxy de interface COM em um cliente chamando CoCreateInstance ou uma de suas variantes. Como efeito colateral desse processo de ativação, às vezes um servidor COM deve ser iniciado para atender à solicitação do cliente. Uma ACL de permissões de inicialização declara quem tem permissão para iniciar um servidor COM. Uma ACL de permissões de acesso declara quem tem permissão para ativar um objeto COM ou chamar esse objeto quando o servidor COM já estiver em execução.

A segunda alteração é que os direitos de chamada e ativação são separados para refletir duas operações distintas e mover o direito de ativação da ACL de permissão de acesso para a ACL de permissão de inicialização. Como a ativação e a inicialização estão relacionadas à aquisição de um ponteiro de interface, os direitos de acesso de ativação e inicialização pertencem logicamente juntos em uma ACL. E como você sempre especifica permissões de inicialização por meio da configuração (em comparação com as permissões de acesso, que geralmente são especificadas programaticamente), colocar os direitos de ativação na ACL de permissão de inicialização fornece ao administrador controle sobre a ativação.

As entradas de controle de acesso de permissão de inicialização (ACEs) são divididas em quatro direitos de acesso:

• Lançamento Local (LL)
• Inicialização remota (RL)
• Ativação local (LA)
• Ativação remota (RA)

O descritor de segurança de permissão de acesso é dividido em dois direitos de acesso:

• Chamadas de Acesso Local (LC)
• Chamadas de Acesso Remoto (RC)

Isso permite que o administrador aplique configurações de segurança muito específicas. Por exemplo, você pode configurar um servidor COM para que ele aceite chamadas de acesso local de todos, enquanto só aceita chamadas de acesso remoto de administradores. Essas distinções podem ser especificadas por meio de alterações nos descritores de segurança de permissões COM.

Por que essas alterações são importantes? Quais ameaças elas ajudam a minimizar?

Versões anteriores do aplicativo de servidor COM não têm como restringir um aplicativo para que ele só possa ser usado localmente sem expor o aplicativo na rede por meio de DCOM. Quando um usuário tem acesso a um aplicativo de servidor COM, ele tem acesso para uso local e remoto.

Um aplicativo de servidor COM pode se expor a usuários não autenticados para implementar um cenário de retorno de chamada COM. Nesse cenário, o aplicativo também deve expor sua ativação a usuários não autenticados, o que pode não ser desejável.

Permissões COM precisas dão flexibilidade ao administrador para controlar a diretiva de permissão COM de um computador. Essas permissões habilitam a segurança para os cenários descritos.

O que passou a funcionar de maneira diferente? Existem dependências?

Para fornecer compatibilidade com versões anteriores, os descritores de segurança COM existentes são interpretados para permitir ou negar o acesso local e remoto simultaneamente. Ou seja, uma entrada de controle de acesso (ACE) permite tanto local quanto remoto, ou nega local e remoto.

Não há problemas de compatibilidade com versões anteriores para direitos de chamada ou inicialização. Há, no entanto, um problema de compatibilidade de direitos de ativação. Se, nos descritores de segurança existentes para um servidor COM, as permissões de inicialização configuradas forem mais restritivas do que as permissões de acesso e forem mais restritivas do que o mínimo necessário para cenários de ativação de cliente, a ACL de permissões de inicialização deverá ser modificada para conceder aos clientes autorizados as permissões de ativação apropriadas.

Para aplicativos COM que usam as configurações de segurança padrão, não há problemas de compatibilidade. Para aplicativos que são iniciados dinamicamente usando a ativação COM, a maioria não tem problemas de compatibilidade, porque as permissões de inicialização já devem incluir qualquer pessoa que seja capaz de ativar um objeto. Caso contrário, esses aplicativos geram falhas de ativação antes mesmo de aplicar o Windows XP SP2 ou o Windows Server 2003 SP1, quando chamadores sem permissão de inicialização tentam ativar um objeto e o servidor COM ainda não está em execução.

Os aplicativos que mais preocupam os problemas de compatibilidade são os aplicativos COM que já foram iniciados por algum outro mecanismo, como o Windows Explorer ou o Gerenciador de Controle de Serviços. Você também pode iniciar esses aplicativos por uma ativação COM anterior, que substitui as permissões de acesso e inicialização padrão e especifica permissões de inicialização que são mais restritivas do que as permissões de chamada. Para obter mais detalhes sobre como resolver esse problema de compatibilidade, consulte "Como resolver esses problemas?" na próxima seção.

Se um sistema atualizado para o Windows XP SP2 ou Windows Server 2003 SP1 for revertido para um estado anterior, qualquer ACE editada para permitir acesso local, acesso remoto ou ambos será interpretada para permitir acesso local e remoto. Qualquer ACE que foi editada para negar acesso local, acesso remoto ou ambos, é interpretada para negar acesso local e remoto. Sempre que desinstalar um service pack, você deve garantir que nenhuma ACEs recém-definida faça com que os aplicativos parem de funcionar.

Como resolvo esses problemas?

Se você implementar um servidor COM e substituir as configurações de segurança padrão, confirme se a ACL de permissões de inicialização específicas do aplicativo concede permissão de ativação aos usuários apropriados. Se isso não acontecer, você deverá alterar a ACL de permissão de inicialização específica do aplicativo para conceder aos usuários apropriados direitos de ativação para que os aplicativos e os componentes do Windows que usam DCOM não falhem. Essas permissões de inicialização específicas do aplicativo são armazenadas no Registro.

As ACLs COM podem ser criadas ou modificadas usando funções de segurança normais.

Quais configurações são adicionadas ou alteradas no Windows XP Service Pack 2?

Na tabela a seguir, essas abreviações são usadas:

LL - Lançamento Local

LA - Ativação Local

RL - Inicialização Remota

RA - Ativação Remota

LC - Chamadas de Acesso Local

RC - Chamadas de Acesso Remoto

ACL - Lista de Controle de Acesso

Quais configurações são adicionadas ou alteradas no Windows Server 2003 Service Pack 1?

Na tabela a seguir, essas abreviações são usadas:

LL - Lançamento Local

LA - Ativação Local

RL - Inicialização Remota

RA - Ativação Remota

LC - Chamadas de Acesso Local

RC - Chamadas de Acesso Remoto

ACL - Lista de Controle de Acesso

Tópicos relacionados

Segurança em COM