Administração do Windows

O ActiveX Installer Service no Windows Vista

Rob Campbell and Joel Yoker

Visão geral:

• Desafios comuns com controles ActiveX
• Como os controles ActiveX são instalados
• Permissões perigosas
• Um processo mais seguro no Windows Vista

É sempre a mesma história. Para melhorar substancialmente sua segurança, você precisa abdicar de alguma liberdade ou flexibilidade. Se o seu ambiente é como a maioria das organizações, você tem um desejo muito forte de proteger o sistema operacional para oferecer um ambiente de computação com mais segurança

para seus usuários finais. Os administradores de TI normalmente resolvem a tarefa de proteger o desktop empregando uma combinação de configurações de diretiva de segurança, permissões de usuário, ACLs (listas de controle de acesso) a registro e arquivos, além de restrições a serviços do sistema.

Um obstáculo comum no desenvolvimento de um ambiente de desktop seguro é descobrir como atenuar as ameaças que envolvem controles ActiveX® maliciosos e, ao mesmo tempo, oferecer um nível apropriado de compatibilidade de aplicativos no seu ambiente. Isso tem sido um desafio com sistemas operacionais de desktop há muitos anos. Felizmente, o novo ActiveX Installer Service (AxIS) no Windows Vista™ resolve os problemas específicos de gerenciamento de controles ActiveX em ambientes corporativos. O AxIS oferece uma forma simples e gerencíável aos usuários padrão (que normalmente não teriam permissão para instalar controles ActiveX) de instalar controles a partir de sites aprovados. O controle de Diretiva de Grupo no AxIS possibilita que os administradores de TI determinem quais controles os usuários podem instalar, independentemente de quais permissões tenham.

Neste artigo, analisamos os desafios administrativos que cercam os controles ActiveX, como essas questões foram resolvidas nas versões anteriores do Windows®, e como o AxIS no Windows Vista oferece um modo único e eficiente de gerenciar a instalação de controles ActiveX.

O que é um controle ActiveX?

Um controle ActiveX é um trecho de código executável (em geral um arquivo OCX empacotado dentro de um arquivo de gabinete) que é instalado e invocado pelo usuário via Internet Explorer®. Os desenvolvedores da Web criam controles ActiveX para adicionar funcionalidade a suas aplicações na Web, que não poderiam ser obtidas facilmente com HTML padrão ou um simples script.

Uma característica importante dos controles ActiveX é seu modelo simples de implantação, do tipo "baixe e execute". Os controles ActiveX são instalados e invocados através da marca de objeto HTML, que tem um atributo chamado CODEBASE que informa ao Internet Explorer (usando uma URL) onde obter o controle, caso já não esteja instalado na máquina do usuário. Neste caso, o Internet Explorer baixa o pacote de instalação associado, realiza uma verificação de confiabilidade no objeto e solicita ao usuário a permissão de instalação por meio da barra de informações do Internet Explorer (mostrada na Figura 1). Durante a instalação, o controle é registrado e invocado pela página de processamento. Após a instalação, qualquer usuário padrão pode invocar o controle. Esse mecanismo simples de distribuição e execução foi feito para propiciar aos desenvolvedores uma forma fácil de distribuir seus componentes aos usuários de seu aplicativo Web. O problema com esse método de distribuição é que os usuários padrão não podem instalar diretamente os controles ActiveX porque são necessários privilégios administrativos para realizar a instalação.

Figura 1** Barra de informações de instalação do controle ActiveX **

Quando os controles ActiveX foram introduzidos no Internet Explorer 4.0, a Internet parecia ser um lugar muito mais amigável. Hoje, o código executável distribuído na Web pode representar uma ameaça significativa, então o Windows permite que somente os usuários com direitos de administrador local instalem controles ActiveX, que posteriormente somente serão instalados se houver aprovação de acordo com as configurações de diretiva. Depois que um controle ActiveX é instalado por um administrador, qualquer usuário do sistema pode invocá-lo. Esse comportamento é facilitado por um conjunto de ACLs de arquivo e registro no Windows. Apesar de isso impedir que os usuários padrão instalem controles ActiveX, os riscos para os administradores locais e usuários padrão (com permissões padrão modificadas) que os instalam não ficam reduzidos.

Ainda que a proteção padrão no Windows — permitindo que somente aqueles com privilégios administrativos realizem a instalação — atenda aos controles ActiveX no nível individual, não atende à forma de gerenciá-los em uma grande organização. Um desafio comum em ambientes corporativos é a forma de permitir o uso de controles ActiveX em que a organização de TI confia e, ao mesmo tempo, atenuar as ameaças potenciais trazidas por controles externos e não-confiáveis. No final das contas, a decisão de instalar um controle ActiveX em particular, bom ou ruim, é normalmente deixada para o usuário individual, dependendo de seus direitos. Para neutralizar as ameaças, algumas organizações bloqueiam todos os controles ActiveX, enquanto outras permitem a instalação pelo usuário final, mas tentam gerenciar todos os malware que forem instalados.

Uma outra forma de impedir a instalação de controles maliciosos é reforçar os direitos restritos do usuário padrão e fazer com que o administrador de TI pré-instale todos os controles exigidos na plataforma do desktop. Isso seria eficiente se os controles ActiveX em uso tivessem uma natureza relativamente estática, fossem modificados usando um processo de lançamento programado em conjunto com atualizações de desktop, ou se a organização usasse um mecanismo de distribuição de software, como o Systems Management Server. No entanto, o gerenciamento contínuo, as necessidades em constante mudança de desenvolvedores de aplicativos internos e as dependências de controles externos continuarão a ser um desafio nessas abordagens.

Em instâncias em que os usuários tenham privilégios administrativos, o problema é diferente, pois está relacionado a impedir que esses usuários instalem controles que não sejam aprovados. Nesses casos, o direito do usuário final de instalar controles ActiveX é assumido, já que o usuário tem privilégios administrativos. (Note que fazer com que os usuários finais executem como administradores local é uma condição que representa um alto risco para a organização e não é recomendada para a maioria dos ambientes corporativos.)

Uma solução é ter um servidor de download de componentes da Internet interno que armazene os controles aprovados. Essa solução requer a modificação da cadeia de caracteres CodeBaseSearchPath no registro do cliente. Em geral, quando uma marca de objeto contendo o atributo CODEBASE é encontrado na página HTML solicitada, os clientes Windows são direcionados para os locais especificados nos dados de CodeBaseSearchPath. Por padrão, essa cadeia de caracteres do registro contém a palavra-chave CODEBASE e URLs de Internet para a galeria de controles ActiveX. Para implementar um servidor de download de componentes da Internet, é preciso substituir os dados padrão em CodeBaseSearchPath pela URL do servidor interno onde você hospedará controles aprovados por sua organização. Assim como a abordagem anterior, essa solução requer um gerenciamento contínuo e traz o custo e a complexidade de hospedar um servidor interno de controles ActiveX.

Há outras soluções, tais como modificar a zona do Internet Explorer URLActions, especificando controles aprovados pelo administrador por meio de Diretiva de Grupo, e bloqueando a instalação de todos os controles no perímetro por meio de regras de firewall. Contudo, como você pode ver, todas essas abordagens têm seus problemas, e muitas são abandonadas devido à falta de flexibilidade. E o que é pior, algumas dessas soluções ainda exigem que o usuário tenha direitos administrativos. No final das contas, essas modificações tentam resolver partes do problema, tais como controlar (ou bloquear) de onde vêm os controles ActiveX, de onde podem ser invocados e assim por diante. No entanto, essas soluções não resolvem o problema fundamental de os usuários sem direitos administrativos não poderem instalar controles ActiveX.

O que o AxIS pode fazer por você?

O AxIS no Windows Vista possibilita que o administrador corporativo gerencie controles ActiveX e, ao mesmo tempo, mantenha uma condição de segurança forte, fazendo com que os usuários executem como usuários padrão, com configurações de sistema de arquivos padrão. O AxIS oferece opções de Diretiva de Grupo para configurar origens confiáveis de controles ActiveX e um processo de "agente" para instalar controles dessas origens confiáveis em nome de usuários padrão. A principal vantagem é que você pode manter uma postura de segurança não-administrativa em estações de trabalho de usuários, em conjunto com um controle administrativo centralizado. O AxIS depende do administrador de TI para identificar as origens confiáveis (normalmente URLs da Internet ou da intranet) de controles ActiveX. Quando uma marca de objeto direciona o Internet Explorer para invocar um controle, o AxIS realiza as seguintes etapas:

1. Verifica se o controle está instalado. Se não estiver, deve ser instalado antes do uso.
2. Verifica a configuração da diretiva AxIS para ver se o controle é de uma origem confiável. A verificação específica relaciona o nome do host da URL especificada no atributo CODEBASE da marca de objeto à lista de locais confiáveis especificada na diretiva.
3. Baixa e instala o controle em nome do usuário.

Se o nome do host da URL de origem não estiver listado na configuração de diretiva AxIS, a solicitação normal de UAC (controle de conta de usuário) será invocada, exigindo direitos administrativos para concluir a instalação. Além disso, o AxIS irá registrar um evento com ID 4097 no log de eventos de aplicativo da origem AxInstallService, descrevendo a tentativa de instalação de controle ActiveX, juntamente com o caminho específico de download para o controle. Um exemplo do evento 4097 é ilustrado na Figura 2. Os dados dessa entrada de log de evento podem ser usados pelo administrador corporativo para modificar a Diretiva de Grupo, permitindo que o controle seja instalado pelo AxIS em visitas subseqüentes ao site.

Figura 2** Evento 4097 de AxInstallService **

AxIS é um componente opcional que vem com os SKUs de Business, Enterprise e Ultimate do Windows Vista, e pode ser habilitado por meio de uma opção autônoma ou pela caixa de diálogo do Painel de Controle (Programas | Programas e Recursos | Ativar e desativar recursos do Windows), conforme é mostrado na Figura 3. Depois de habilitado, o AxIS realiza as etapas descritas acima toda vez que um controle é solicitado pelo Internet Explorer.

Figura 3** Habilitando o AxIS no Painel de Controle **

A capacidade de anexar tarefas a eventos no Windows Vista representa uma maneira fácil de um administrador receber uma notificação do serviço AxIS, por exemplo, quando a instalação de um controle ActiveX é bloqueada. É importante notar que não se pode sempre assumir que o controle ActiveX será instalado a partir do mesmo nome de host de URL que o usuário final está acessando de seu site. Por esse motivo, as informações fornecidas pelo evento 4097 do AxInstallService (tentativa de instalação) podem se tornar extremamente úteis na identificação do host a partir do qual o controle tenta ser instalado.

Com as informações que você obtém do evento, pode configurar o local confiável na Diretiva de Grupo. As definições de AxIS na Diretiva de Grupo ou Local encontram-se nas definições de Configuração do Computador (como se observa na Figura 4). A definição da diretiva de sites de instalação aprovados para controles ActiveX possibilita que você especifique URLs de host de locais confiáveis (consulte a Figura 5). A definição de site aprovado requer dois tipos de informação: de onde o controle ActiveX pode ser instalado e o comportamento da instalação.

Figura 4** Definições no Editor de Objeto de Diretiva de Grupo **

Figura 5** Sites de instalação aprovados pelo AxIS **

Primeiro, como já mencionado antes, é necessário uma URL de host para indicar o local confiável do controle. Ao contrário das soluções anteriores, que requerem o conhecimento do CLSID do controle (que normalmente muda quando os controles são revisados por seus desenvolvedores), o AxIS permite que qualquer controle seja instalado a partir do local confiável, reduzindo a carga administrativa geral. O segundo tipo de informação é uma cadeia de caracteres de quatro valores delimitada por vírgula, cada um dos valores ditando o comportamento da experiência de download do controle ActiveX. Os valores especificam quatro propriedades: TPSSignedControl, SignedControl, UnsignedControl e ServerCertificatePolicy. As duas primeiras propriedades (TPSSignedControl e SignedControl) podem ter um dos três valores: 0, 1 ou 2. Esses valores são similares aos valores encontrados nas definições URLAction. Um valor 0 impede que o controle seja instalado, um valor 1 faz com que o usuário receba uma solicitação de permissão para instalar, e um valor 2 faz com que o controle seja instalado silenciosamente em nome do usuário. Controles sem assinatura não podem ser instalados silenciosamente e, portanto, o valor de UnsignedControl só pode ser 0 ou 1. Note que, se não for especificada nenhuma diretiva, os valores padrão de 2, 1 e 0 serão usados.

A propriedade final especifica o comportamento da instalação com base nas configurações de certificado do controle de configurações assinado. Assim como a maioria dos sites SSL, os certificados devem passar por uma série de testes de segurança para garantir que o certificado seja válido. Propriedades de certificado inválidas às vezes são a realidade de uma implementação de controles ActiveX assinados do mundo real. Com sua configuração, o AxIS permite que os administradores reduzam as informações inválidas que às vezes são apresentadas por certificados, URL-a-URL. A propriedade final é representada como uma combinação de bitmask dos valores mostrados na Figura 6.

Figure 6 ServerCertificatePolicy

A configuração padrão é 0, significando que deve passar por todas as verificações de segurança para que o AxIS complete a instalação. A combinação da configuração de host e esses quatro valores é especificada na definição de diretiva, conforme visto na Figura 7.

Figura 7** URLs de host AxIS aprovados **

Conclusão

O AxIS possibilita que você configure a Diretiva de Grupo para controlar quais controles ActiveX os usuários podem instalar sem precisar de privilégios administrativos ou configurações complexas. O controle nesse nível poderia ser desafiador em versões anteriores do Windows, e as soluções disponíveis anteriormente costumavam apresentar limitações graves ou uma grande sobrecarga de gerenciamento. O AxIS oferece às organizações outra ferramenta voltada para uma abordagem de privilégios mínimos para direitos de usuários finais em sistemas de desktop, possibilitando a implementação de um modelo de usuário padrão em que os usuários finais não precisam ter privilégios administrativos. O Windows Vista coloca o administrador de TI de volta no banco de motorista ao ter o poder de escolher quais controles ActiveX são confiáveis dentro do ambiente corporativo, determinados pela organização, não pelo usuário final.

Rob Campbell é um especialista técnico sênior da equipe Microsoft Federal. Rob está concentrado no desenvolvimento e na implantação de soluções de segurança para clientes do governo federal dos Estados Unidos.

Joel Yoker é um consultor sênior da equipe Microsoft Federal. Joel está concentrado no desenvolvimento e na implantação de soluções de segurança para clientes do governo federal dos Estados Unidos.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..