Bem-vindo ao curso de treinamento em Windows XP Service Pack 2 para desenvolvedores.

Introdução

Bem-vindo ao curso de treinamento em Windows XP Service Pack 2 para desenvolvedores. O objetivo deste curso é fazer com que você, desenvolvedor, tome conhecimento das implicações relacionadas à implantação do Service Pack 2 em computadores que rodem em Windows XP Professional e Windows XP Home Edition.

Especificamente, ao término deste curso, o aluno estará apto a:

1. Resumir as justificativas para uma maior segurança no Windows XP SP2. 2. Identificar as quatro áreas de desenvolvimento afetadas por este service pack. 3. Rever a situação atual. 4. Identificar as áreas comuns em que os aplicativos irão quebrar após a implantação do XP SP2. 5. Identificar as possíveis correções a curto prazo e as soluções a longo prazo. 6. Explicar como os exemplos de atualizações de aplicativos permitem que o desenvolvedor tire proveito das alterações feitas pelo XP SP2. 7. Descrever as próximas etapas que devem ser efetuadas para corrigir os problemas que podem surgir com a instalação do XP SP2.

O Windows XP Service Pack 2 é mais do que um conjunto normal de correções de bug para o principal sistema operacional da Microsoft. Ele também está sendo usado para fornecer uma atualização significativa que visa aprimorar a segurança do Windows XP e simplificar o processo de atualização do software.

A segurança tornou-se a principal questão para todos os usuários Windows, sejam eles corporativos ou consumidores. Os vírus têm sido um problema praticamente desde que os PCs foram lançados, mas hoje a Internet – e, particularmente, a ampla disponibilidade de conexões contínuas em banda larga na rede – causaram um aumento dramático no número e na gravidade dos ataques. Considere os dados a seguir:

Drivers de segurança

Com o número de incidentes em permanente ascensão, a Microsoft decidiu fazer um esforço proativo para aumentar consideravelmente a segurança das famílias de sistemas operacionais Windows XP e Windows Server 2003. Por isso, o Windows XP Service Pack 2 fornece vários recursos novos e aprimorados, destinados ao aumento da segurança do sistema operacional e dos aplicativos.

Impacto da ferramenta para o desenvolvedor

O desenvolvedor precisa estar a par de três pontos significativos antes de aprofundar-se nos detalhes do Service Pack 2 para Windows XP.

1. A Microsoft desenvolveu uma abordagem em 3 camadas para oferecer suporte ao SP2 nos produtos Windows .NET Framework e Visual Studio.

a. Do Visual Studio "Whidbey" em diante, todos os produtos serão projetados para funcionar bem no XP SP2 e para permitir que os desenvolvedores tirem amplo proveito das melhorias de segurança ao usarem o Visual Studio nos próprios aplicativos e máquinas.

b. As versões 2002 e 2003 do .NET Framework (ou seja, versões 1.0.3705 e 1.1.4322) e o Visual Studio serão reparadas conforme necessário para permitir que os desenvolvedores tirem proveito das melhorias do XP SP2 em seus aplicativos, bem como para solucionar degradações de funcionalidade em ferramentas significativas (se houver). Os service packs do .NET Framework que fazem uso do Execution Protection serão fornecidos no XP SP2 RTM timeframe. O Visual Studio será reparado dentro do prazo de manutenção normal.

c. As ferramentas lançadas antes do VS .NET 2002 não serão ajustadas para lidar com o XP SP2. Houve vários aprimoramentos de segurança significativos no VS .NET 2002 e posterior, e a atualização para esses produtos envolverá custos extras para os desenvolvedores que não somente precisem instalar um novo conjunto de ferramentas e service pack como também reconstruir, testar e redistribuir os produtos. A Microsoft se esforçará para assegurar que essas ferramentas continuem a funcionar corretamente no XP SP2; no entanto, é possível que essas ferramentas não se beneficiem da segurança aprimorada do XP SP2.

2. O .NET Framework "Whidbey" está sendo projetado para se tornar o modelo de regra de segurança para os produtos usados pelo desenvolvedor.

3. Problemas relacionados às ferramentas afetarão o desenvolvedor em sua experiência de desenvolvimento.

Impacto no aplicativo personalizado

O Service Pack 2 introduz um conjunto de tecnologias de segurança que aumentará a capacidade de os computadores baseados em Windows XP suportarem ataques mal-intencionados por parte de vírus e worms. As tecnologias abrangem as áreas a seguir.

• Proteção de rede aprimorada – As tecnologias de segurança incluídas no Service Pack 2 possibilitarão maior proteção contra ataques baseados na rede, tais como o worm MSBlaster e suas variações. Para obter mais informações, consulte http://www.microsoft.com/security/incident/blast.asp. Essa segurança é obtida por meio de uma série de inovações e aprimoramentos. Agora, o Windows Firewall fica ativado por padrão, e todas as portas permanecem fechadas exceto quando em uso. Houve melhorias na compatibilidade do aplicativo quando o Windows Firewall está ativo, além de aprimoramentos na administração corporativa (enterprise administration) do Windows Firewall (através de políticas de grupo - Group Policy). Foram adicionadas restrições de controle de acesso (access control restrictions) à infra-estrutura DCOM e, através da execução do serviço RPC com privilégios limitados, reduziu-se a exposição de sua superfície de ataque.

• Nova proteção de memória (New Memory Protection) - Para oferecer mais proteção contra ataques que permitem copiar grandes volumes de dados para as áreas de memória de um computador (buffer overruns), a Microsoft está empregando várias tecnologias. Os componentes básicos do Windows estão sendo recompilados com a versão mais atual da tecnologia de compilador para diminuir os buffer overruns. O trabalho continua com os fornecedores de microprocessadores, para ajudar o Windows a oferecer suporte a hardware "no execute" (NX) em microprocessadores que trabalham com o recurso. Esse recurso permite que a CPU obrigue a separação do código e dos dados do aplicativo, impedindo que um componente execute um código de programa que contenha um worm ou vírus na área de memória reservada para os dados.

• Melhoria na segurança de Email (Improved Email Security) – A Microsoft adicionou novas tecnologias de segurança de e-mail que ajudarão a impedir que os vírus (como o SoBig.F) se espalhem no e-mail e nas mensagens instantâneas. Os anexos potencialmente perigosos enviados por e-mails e por mensagens instantâneas serão isolados, a fim de que não possam afetar outras partes do sistema. Além disso, as configurações padrão agora fornecem controles de anexo para o Outlook Express e Windows messenger, e a segurança e confiabilidade foram aumentadas para o Outlook Express.

• Aumento da segurança na navegação (Enhanced Browsing Security) - As tecnologias de segurança que foram adicionadas ao Service Pack 2 fornecem mais proteção contra conteúdo malicioso na Web. Duas dessas tecnologias incluem o bloqueio na zona Local Machine para impedir a execução de scripts mal-intencionados e fortalecimento contra downloads na Web perigosos, e a inclusão de um Pop-up Manager para impedir ataques de falsificações de interface do usuário. Além disso, as interfaces e controles de usuário foram melhoradas para ajudar a impedir a execução de controles ActiveX e spyware nas máquinas clientes sem o conhecimento ou a permissão destes.

Juntas, essas tecnologias de segurança ajudarão a dificultar os ataques ao Windows XP, mesmo que o sistema não contenha as últimas atualizações ou patches instalados. Além disso, elas são particularmente úteis para reduzir os worms e vírus.

Muitos clientes não conseguem ou não podem implementar os patches assim que eles são lançados. No entanto, eles ainda precisam estar protegidos contra os riscos minimizados pelos patches. Ao implantar o Service Pack 2 em computadores Windows XP, a Microsoft está entregando tecnologias de segurança que fornecem proteção adicional mesmo antes de implantar um patch. As tecnologias de segurança listadas acima consistem nas etapas seguidas pela iniciativa Trustworthy Computing para tornar os sistemas dos consumidores mais sólidos.

Embora muitos aplicativos não necessitem de atenção, a funcionalidade de alguns deles poderá ser prejudicada pelas novas tecnologias introduzidas com o service pack. Por exemplo, o Windows Firewall permanecerá ativado por padrão após a instalação do Service Pack 2. Isso, por sua vez, afetará ações como depuração remota (remote debugging) no Visual Studio e conexões de entrada e saída de aplicativos, serviços e portas RPC e DCOM.

O conhecimento antecipado dessas principais alterações permitirá que o desenvolvedor (juntamente com o profissional de TI) se prepare para implementar o Service Pack 2 na rede.

Além das melhorias na tecnologia de segurança, a Microsoft também adicionou o Improved Computer Maintenance ao SP2, o que inclui:

• atualizações automáticas "silenciosas" para consumidores.

• download inteligente de dados de atualização em conexões de baixa largura de banda.

• uma nova Security Center (Central de Segurança) para centralizar o gerenciamento de patches.

• melhores opções de segurança no Windows Installer.

• uma versão mais sólida do site Microsoft's Windows Update para oferecer mais disponibilidade e resistir a ataques de negação de serviço (DOS - denial-of-service).

Os usuários Enterprise podem empregar essas tecnologias para fornecer gerenciamento inteligente de patch interno. Essas alterações afetarão principalmente os usuários e administradores de SI/TI, mas poderão vir a se tornar problema para desenvolvedores de aplicativos que precisem assegurar compatibilidade com a versão revisada do Windows Installer.

Para compreender melhor o significado das alterações feitas pelo XP Service Pack 2, consulte a tabela 2.

Alteração no XP SP2 Dev. Web Dev. aplicativo

Admin. SI/TI

Usuários

Proteção de rede aprimorada X X X X

Nova proteção de memória X

Melhoria na segurança de Email X X X

Aumento da segurança na navegação X X X

Tabela 2: implicações decorrentes de alterações feitas pelo XP SP2

Nas próximas seções, você terá oportunidade de rever em detalhes as alterações.

Proteção de rede aprimorada Com o Windows XP Service Pack 2, a Microsoft está investindo em três tecnologias-chave que deixarão os sistemas menos vulneráveis a ataques na rede. são elas: Windows Firewall, restições na Interface RPC e aprimoramento da segurança do DCOM.

• Windows Firewall

• RPC Interface Restrictions

• DCOM Security Enhancements

Windows Firewall O Windows Firewall consiste em um firewall de filtragem stateful para Windows XP e Windows Server 2003. Ele fornece proteção para PCs conectados à rede, rejeitando conexões de entrada não solicitadas através do TCP/IP versão 4 (IPv4). O SP2 ativa o Windows Firewall por padrão e o inicializa mais cedo no processo de boot. Dentre esses novos recursos, seis podem afetar diretamente os aplicativos existentes.

• Ativado por padrão

Antes do SP2, o Windows XP era fornecido com o Windows Firewall desativado por padrão. Os usuários precisavam executar um assistente ou navegar pela pasta Network Connections para ativar o Windows Firewall. Com o Windows Firewall ativado por padrão, o computador ficará protegido dos muitos ataques baseados na rede. Se o Windows Firewall estivesse ativado por padrão, o recente ataque do MSBlaster teria tido muito menos impacto, independentemente de os usuários terem patches atualizados, já que o Windows Firewall descarta comunicações não solicitadas, tais como varredura de porta (port scanning). O Windows Firewall ativado por padrão (On-by-Default) pode interferir nos aplicativos existentes se o aplicativo não funcionar com a filtragem stateful por padrão. Por exemplo, se o aplicativo espera receber mensagens de outro computador sem primeiro enviar uma mensagem (isto é, atue como cliente e como servidor), ele pode falhar. Além disso, os PCs que estiverem executando um servidor Web exigirão que o Windows Firewall seja configurado para permitir essas solicitações (http://support.microsoft.com/default.aspx?scid=kb;EN-US;320855).

• Segurança no momento do boot

Nas versões anteriores do Windows, existe um intervalo de tempo entre o momento em que a pilha da rede é executada e o momento em que o Windows Firewall fornece proteção. Isso possibilita que um pacote seja recebido e enviado para um serviço sem a filtragem do Windows Firewall, o que expõe o computador a vulnerabilidades. Isso acontece porque o driver do firewall só é iniciado para filtragem depois que o serviço do firewall é carregado e aplica a política apropriada. O serviço do firewall possui diversas dependências, o que faz com que ele precise aguardar até que elas sejam liberadas para que possa aplicar a política no driver. Esse período de tempo é baseado na velocidade do computador. No Windows XP Service Pack 2, o driver do firewall tem uma regra estática, denominada política de tempo de boot (boot-time policy). Ela realiza a filtragem stateful e elimina o tempo de vulnerabilidade enquanto o computador está iniciando. Essa nova regra de política permite que o computador abra as portas para que as tarefas de rede básicas, como DNS e DHCP, possam ser realizadas. Ela também permite a comunicação com um controlador de domínio para obter as políticas apropriadas. Quando o serviço do firewall estiver em execução, ele carregará (e aplicará) a política do Windows Firewall em tempo de execução (run-time Windows Firewall policy) e removerá os filtros do tempo de boot. (A política de tempo de boot não pode ser configurada.) Não existe segurança de tempo de boot se a opção Windows Firewall/Internet Connection Sharing (ICS) estiver definida como Disabled.

• Configuração mais fácil Agora, o Windows Firewall é mais fácil de configurar, já que permite configurar globalmente todas as interfaces de modo que as alterações sejam aplicadas automaticamente a todas as conexões de rede novas ou já existentes. As configurações individuais ainda poderão ser realizadas. Além disso, o Windows Firewall permite que você crie dois conjuntos de política de firewall: uma para quando o computador estiver conectado à rede corporativa e outra para quando não estiver. Você pode especificar uma política que seja menos rígida quando o computador estiver conectado à rede corporativa para permitir o funcionamento da linha de aplicativos comerciais. Você também pode ter uma política de segurança mais agressiva, que seja reforçada quando o computador deixar a rede da empresa, e que o ajude a se proteger contra ataques baseados na Internet. No entanto, os vários perfis do Windows Firewall só se aplicam a computadores que sejam ligados a um domínio. Os computadores que pertencem a um dado grupo de trabalho (workgroup) só possuem um perfil. Os administradores podem agora usar o utilitário de linha de comando Netsh helper (antes disponível apenas com o Advanced Networking Pack for Windows XP) para fazer o seguinte:

o Adicionar ou remover aplicativos da lista de permissões do Windows Firewall

o Configurar o estado padrão do Windows Firewall (Off, Enabled, On com No Exceptions)

o Configurar quais portas devem ser abertas, incluindo se as portas permitem acesso global ou acesso restrito à sub-rede local e se as portas estão abertas em todas as interfaces ou para cada interface

o Configurar as opções de logging

o Configurar as opções de tratamento de ICMP (Internet Control Message Protocol) Note que o Service Pack 2 também inclui novos GPOs (Group Policy Objects) para permitir que os administradores de rede gerenciem a política do Windows Firewall no ambiente corporativo. Esses GPOs incluem o modo Operational (On, Off, ou On with No Exceptions), Allowed Programs, Opened Ports (static), ICMP settings e Enable RPC. Eles podem ser configurados tanto nos perfis corporativos como padrão.

• Lista de permissões de aplicativo (Windows Firewall Permissions List)

Alguns aplicativos atuam tanto como clientes de rede como servidores. Quando atuam como servidores, eles precisam autorizar que o tráfego de entrada não solicitado seja recebido, já que eles

não sabem com antecedência quem será o parceiro (peer). Nas versões anteriores do Windows, um aplicativo precisava chamar as APIs do Windows Firewall para permitir que as portas de escuta (listening ports) necessárias fossem abertas. Isso se tornou uma dificuldade nas situações peer-to-peer em que a porta não era conhecida com antecedência. Cabia ao aplicativo fechar a porta novamente após o término da comunicação. Sem isso, poderia haver aberturas desnecessárias no firewall se o aplicativo terminasse de forma inesperada. Além disso, essas portas só poderiam ser abertas se os aplicativos estivessem sendo executados no contexto de segurança de um administrador local. Isso viola o princípio de privilégio reduzido, já que exige que os aplicativos sejam executados em um contexto administrativo, em vez de apenas com os privilégios mínimos necessários. No Windows XP Service Pack 2, é possível adicionar à lista de permissões do Windows Firewall um aplicativo que “escute” a rede, tanto de forma administrativa como programática. Se o aplicativo estiver na lista de permissões de aplicativo (lista de permissões do Windows Firewall), o Windows abrirá automaticamente a porta necessária, independentemente do contexto de segurança do aplicativo, pelo tempo em que o aplicativo estiver escutando nessas portas. O aplicativo não pode abrir nenhuma porta que não esteja usando, já que isso que pode deliberadamente ou inadvertidamente expor outro aplicativo ou serviço ao tráfego da rede. Isso também permite que os aplicativos que façam escuta de rede sejam executados como um usuário regular (em vez de como um administrador), como era o caso nas versões anteriores do Windows. Os aplicativos que não fazem escuta de rede não precisam se preocupar nem precisam ser colocados na lista de permissões do aplicativo (Application Permissions List). Se você não precisar adicionar um aplicativo à lista Firewall Permissions graficamente, o administrador poderá selecionar Configure Windows Firewall no painel Network Tasks (quando estiver exibindo conexões de rede) ou por meio do botão Settings na guia Advanced de uma conexão de rede específica. A caixa de diálogo resultante mostrada na Figura 1 permite que um administrador ative o Windows Firewall com exceções (On with exceptions, isto é, a lista branca está ativa), sem exceções ("On with No Exceptions") ou desative-o (Off).

Figura 1: Guia General do Windows Firewall

Quando a primeira opção é escolhida, a lista de permissões do Windows Firewall disponível na guia Exceptions é usada de acordo com a Figura 2.

Figura 2: Guia Exceptions do Windows Firewall Para adicionar um aplicativo à lista de permissões do Windows Firewall, o administrador clica no botão Add e configura o aplicativo executável conforme mostrado na Figura 3. Note que também é possível ativar as portas TCP e UDP individuais nesta caixa de diálogo.

Figura 3: Caixa de diálogo Exceptions do Windows Firewall Os administradores também podem gerenciar a lista de permissões do Windows Firewall usando o utilitário de linha de comando Netsh mencionado mais cedo.

• Suporte a RPC

Nas versões anteriores do Windows, o Windows Firewall bloqueava a comunicação por RPC (remote procedure call). Embora o Windows Firewall possa ser configurado para autorizar o tráfego da rede para o RPC Endpoint Mapper, os aplicativos que usavam endpoints dinâmicas tinham o tráfego RPC bloqueado pelo Windows Firewall devido à escolha arbitrária de porta da rede do RPC. Muitos aplicativos e componentes falham se o RPC não está autorizado a se comunicar na rede. Alguns exemplos incluem (mas não se limitam a) o seguinte:

o Compartilhamento de arquivos e impressão

o Administração remota

o Configuração do WMI (Remote Windows Management Instrumentation)

o Scripts que gerenciam clientes e servidores remotos

O RPC abre várias portas e portanto, expõe muitos servidores diferentes nestas portas. Em um típico servidor ou estação de trabalho, existem aproximadamente 60 servidores RPC (rodando por padrão) que escutam as solicitações dos clientes na rede. Alguns servidores possuem mais, dependendo de suas configurações. Essa é a superfície de ataque ao RPC.

Pelo fato de existirem tantos servidores RPC incluídos no Windows XP, e como a maioria deles roda usando o mesmo nome de arquivo de imagem de processo (Svchost.exe), o Windows Firewall adota uma abordagem diferente para os servidores RPC. Ao abrir uma porta, o chamador pode reivindicar

que a porta seja para ser usada para RPC. O Windows Firewall só aceitará essa reivindicação se o chamador estiver sendo executado no sistema local (Local System), no serviço de rede (Network Service) ou em contextos de segurança do serviço local (Local Service security contexts). O Windows Firewall oferece suporte a uma flag de nível (profile level flag) que permite que as portas RPC sejam abertas mesmo que o chamador não esteja na lista de permissões do Windows Firewall.

Ele é armazenado no registro como o valor REG _DWORD, denominado PrivilegedRpcServerPermission abaixo da profile key. Os valores correspondem à enumeração NET_FWV 4_SERVICE_PERMISSION:

o NET_ FWV 4_SERVICE_BLOCK = 0. Os servidores RPC só estarão autorizados a abrir portas se estiverem na lista de permissões do Windows Firewall.

o NET_ FWV 4_SERVICE_ALLOW_LOCAL = 1. Se um servidor RPC não estiver na lista de permissões do Windows Firewall, a porta será aberta, mas só aceitará o tráfego de rede proveniente da sub-rede local.

o NET_ FWV 4_SERVICE_ALLOW_ALL = 2. Se um servidor RPC não estiver na lista de permissões do Windows Firewall, a porta será aberta para o tráfego de rede proveniente de qualquer sub-rede.

Note, no entanto, que as configurações do aplicativo autorizado sempre substitui a configuração RPC genérica. Por exemplo, se a configuração do RPC for permitir local, mas o servidor RPC executável também estiver na lista de permissões do Windows Firewall com a opção de somente sub-rede local (Local Subnet Only) definida como False, a porta do RPC será aberta a todas as sub-redes.

• On with No Exceptions

O Windows Firewall pode ser configurado para autorizar tráfego de entrada não solicitado durante o uso normal. Isso geralmente ocorre porque é necessário ativar cenários-chave, tais como compartilhamento de impressora e de arquivos. Caso seja descoberto um problema de segurança em um ou mais dos serviços Windows de escuta, é possível que o computador precise mudar para o modo somente-cliente (client-only), On with No Exceptions. Alternar para esse modo somente-cliente faz com que Windows Firewall bloqueie o tráfego de entrada não solicitado sem precisar reconfigurar o firewall. Esse modo pode ser configurado por meio da opção On with no exceptions mostrada na Figura 1. Quando o sistema estiver nesse modo, todos os buracos estáticos serão fechados. Qualquer chamada de API para abrir um buraco estático será autorizada e a configuração armazenada, mas ela não será aplicada até que o modo operacional do Windows Firewall seja retornado à operação normal. As solicitações de escuta feitas pelos aplicativos também serão ignoradas.

Lembre-se de que vírus, worms e atacantes buscam por serviços para explorar. Quando está nesse modo operacional, o Windows Firewall ajuda a impedir ataques desses tipos. O computador não pode escutar as solicitações de entrada da rede, mas as conexões de saída serão efetuadas com êxito.

Firewall – Implicações para o desenvolvedor Implicações para o desenvolvedor

Para o desenvolvedor, as implicações relacionadas às alterações no Windows Firewall dependem do tipo de conexão utilizada pelo aplicativo. Por exemplo, conexões de saída e de entrada IPv4, conexões de entrada IPv4 para serviços, e conexões de entrada IPv4 para RPC e DCOM.

Conexões de saída IPv4 (Ipv4 outbound connections)

Descrição

Para o consumidor típico e computadores de escritório, pouco tráfego da rede é não solicitado. O Windows Firewall considera o tráfego de saída e as respostas correspondentes como sendo os componentes das conexões de saída. Todas as conexões de saída são automaticamente autorizadas pelo Windows Firewall. Para obter mais informações sobre o que o tráfego da rede do Windows Firewall permite como parte de conexões de saída TCP (Transmission Control Protocol) e UDP (User Data Protocol), consulte as observações abaixo.

Ação exigida

Nenhuma. O Windows Firewall permitirá automaticamente todas as conexões de saída, independentemente do programa e do contexto do usuário.

Notas

• Quando um computador inicia uma conexão TCP com um computador remoto, o Windows Firewall autoriza o tráfego TCP somente para a porta de origem da conexão TCP a partir do endereço IP (Internet Protocol) para o qual a conexão foi iniciada.

• Quando um computador envia pacotes UDP, o Windows Firewall autoriza o UDP para a porta a partir da qual os pacotes UDP foram enviados a partir de qualquer endereço IP, por um período de 90 segundos.

• As respostas de Unicast ao tráfego multicast e broadcast são autorizadas através do Windows Firewall por 500 milissegundos se forem direcionadas para a porta a partir da qual o tráfego multicast foi enviado e vierem de endereços IP localizados na mesma sub-rede que o computador. Uma configuração no firewall controla esse comportamento, que é ativado por padrão para outro perfil do firewall.

Exemplos

• Surfando na Web com o Microsoft Internet Explorer

• Verificando e-mails no Outlook Express

• Batendo papo no MSN Messenger ou no Windows Messenger

Conexões de entrada IPv4 para aplicativos (IPv4 inbound connections for applications)

Descrição

Este cenário abrange um aplicativo que completa uma operação de escuta em um soquete TCP (TCP socket) ou se vincula de forma bem-sucedida a um soquete UDP através do Winsock. Neste cenário, o Windows Firewall pode automaticamente abrir e fechar portas conforme solicitado pelo aplicativo.

Ação exigida

Quando um aplicativo que precise escutar uma porta estiver sendo instalado por um administrador, os usuários precisam indicar se desejam permitir que o aplicativo abra portas no firewall.

Se o usuário consentir, o aplicativo deverá usar de forma programática o ICF API Set documentado em http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ics/ics/icf_plus_intro.asp para se auto-adicionar à lista de permissões de ICF. Esse conjunto de objetos COM permite que um desenvolvedor registre e configure as configurações de perfil do ICF.

O aplicativo que é mostrado abaixo exibindo as informações de configuração e usando a API é fornecido neste curso. Veja a Figura 4.

Figura 4: Aplicativo

Isso exigirá o uso da interface COM INetFwV4AuthorizedApplication ou da classe COM NetFwV4AuthorizedApplication para adicionar o aplicativo à coleção AuthorizedApplications do objeto de perfil atual por meio da interface INetFwV4Profile (marcada como Enabled).

Se o usuário não consentir, o aplicativo deverá usar o ICF API Set para se auto-adicionar à coleção AuthorizedApplications como Disabled.

Quando você usar a interface INetFwV4AuthorizedApplication para adicionar um aplicativo à coleção AuthorizedApplications, os seguintes valores serão obrigatórios:

• Image File Name. Este é o arquivo que chama o Winsock para ouvir o tráfego da rede. Esse deve ser um caminho totalmente qualificado, mas pode conter variáveis de ambiente.

• Friendly Name. Este é o nome do aplicativo que será mostrado aos usuários na interface de usuário do Windows Firewall.

Estes são os valores opcionais:

• Local Subnet Only. Por padrão, quando há uma porta aberta, todo o tráfego da rede é autorizado a passar por ela. Se um aplicativo precisar receber o tráfego apenas de sub-rede local, por exemplo, use esse valor.

• Enabled. Por padrão, a entrada para um aplicativo na coleção AuthorizedApplications é ativada. Conforme descrito acima, esse valor deve ser usado para adicionar a entrada do aplicativo como Disabled, se o usuário não consentir na abertura de portas do aplicativo. Isso permitirá que o usuário veja o aplicativo na interface de usuário do Windows Firewall e o ative mais tarde.

O ICF monitora o Winsock para ver quando o aplicativo começa e termina de escutar as portas. Como resultado, as portas serão automaticamente abertas e fechadas para os aplicativos assim que suas entradas tiverem sido ativadas na lista de permissões de ICF. Isso significa que os aplicativos Winsock não exigem nenhuma ação para abrir e fechar as portas.

Código de exemplo

Para fins de exemplo do uso de um ICF API Set, considere um aplicativo que seja instalado por meio do Windows Installer. Um desenvolvedor que utiliza o Visual Studio .NET poderia criar um projeto de configuração que solicite através de um prompt que o usuário adicione o aplicativo à lista de permissões de ICF e, em seguida, execute a instalação usando uma classe Installer. Para isso, seria necessário realizar as seguintes etapas:

1. Criar uma assembly Class Library no Visual Studio .NET

2. Adicionar uma referência à NetFwV4TypeLib type library na guia COM da caixa de diálogo Add Reference, conforme mostrado abaixo. Isto criará um COM interop assembly através da qual o ICF API Set será chamado pelo código gerenciado. Observe que esse componente COM está instalado no Windows XP Service Pack 2. Veja a Figura 5.

Figura 5: Criando o COM interop assembly.

3. Adicione uma referência ao assembly System.Configuration.Install.dll

4. Adicione uma classe ao projeto ICFAppListInstaller

5. Importe ou use o NetFwV4TypeLib e o namespace System.Configuration.Install da seguinte maneira:

[VB .NET] Imports System.Configuration.Install Imports NetFwV4TypeLib

[C#] using System.Configuration.Install; using NetFwV4TypeLib;

1. Adicione um código à classe conforme mostrado a seguir:

[VB .NET] < RunInstaller(True) > _ Public Class ICFAppListInstaller Inherits Installer

Private name, image, enabled, local As String Private appEnabled As Boolean = False Private localSubnetOnly As Boolean = True

Public Overrides Sub Uninstall(ByVal state As IDictionary) GetArgs() Dim objV4Mgr As NetFwV4MgrClass Try objV4Mgr = New NetFwV4MgrClass Catch ex As Exception ' Não foi possível instanciar; talvez o XPSP2 não esteja em execução Context.LogMessage("Could not instantiate NetFwV4Mgrclass [" & _ ex.Message & "]") Return End Try

Try ' Remova o aplicativo da lista de permissões RemoveFromPermissionsList(image, objV4Mgr.LocalPolicy.CurrentProfile) MyBase.Uninstall(state) Catch e As Exception Context.LogMessage(e.Message) Throw New InstallException(e.Message) End Try End Sub Public Overrides Sub Install(ByVal state As IDictionary) GetArgs() MyBase.Install(state) Dim objV4Mgr As NetFwV4MgrClass Try objV4Mgr = New NetFwV4MgrClass Catch ex As Exception ' Não foi possível instanciar; talvez o XPSP2 não esteja em execução Context.LogMessage("Could not instantiate NetFwV4Mgrclass [" & _ ex.Message & "]") Return End Try Try ' Adicione o aplicativo à lista de permissões AddToPermissionsList(name, image, appEnabled, _ objV4Mgr.LocalPolicy.CurrentProfile) Catch e As Exception Context.LogMessage(e.Message) Throw New InstallException(e.Message) End Try End Sub

Private Sub GetArgs() ' Obtenha os argumentos com o instalador name = Me.Context.Parameters.Item("Name") If name = "" Then Throw New InstallException("No name specified") End If image = Me.Context.Parameters.Item("Image") If image = "" Then Throw New InstallException("No image name specified") End If enabled = Me.Context.Parameters.Item("Enabled")

Select Case enabled.ToUpper Case "1" appEnabled = True Case "0" appEnabled = False End Select local = Me.Context.Parameters.Item("LocalSubnet") Select Case local Case "1" localSubnetOnly = True Case "0" localSubnetOnly = False End Select End Sub Private Sub AddToPermissionsList(ByVal name As String, ByVal imageName As String, _ ByVal enabled As Boolean, ByVal profile As INetFwV4Profile) ' Adicione o aplicativo à lista de permissões de ICF Dim app As New NetFwV4AuthorizedApplication app.Enabled = enabled app.LocalSubnetOnly = localSubnetOnly app.Name = name app.ProcessImageFileName = imageName profile.AuthorizedApplications.Add(app) End Sub Private Sub RemoveFromPermissionsList(ByVal imageName As String, _ ByVal profile As INetFwV4Profile) ' Remova o aplicativo da lista de permissões de ICF profile.AuthorizedApplications.Remove(imageName) End Sub End Class

[C#] [RunInstaller(true)] public class ICFAppListInstaller : Installer { private string name, image, enabled, local; private bool appEnabled = false; private bool localSubnetOnly = true; public override void Uninstall(IDictionary state) { GetArgs(); NetFwV4MgrClass objV4Mgr = null; try { objV4Mgr = new NetFwV4MgrClass(); } catch (Exception ex) { // Não foi possível instanciar; talvez o XPSP2 não esteja em execução Context.LogMessage("Could not instantiate NetFwV4Mgrclass [" + ex.Message + "]"); return; } try { // Remova o aplicativo da lista de permissões RemoveFromPermissionsList(image, objV4Mgr.LocalPolicy.CurrentProfile); base.Uninstall(state); } catch (Exception e)

{ Context.LogMessage(e.Message); throw new InstallException(e.Message); } } public overrides void Install(IDictionary state) { GetArgs(); base.Install(state); NetFwV4MgrClass objV4Mgr = null; try { objV4Mgr = new NetFwV4MgrClass(); } catch (Exception ex) { // Não foi possível instanciar; talvez o XPSP2 não esteja em execução Context.LogMessage("Could not instantiate NetFwV4Mgrclass [" + ex.Message + "]"); return; } try { // Adicione o aplicativo à lista de permissões AddToPermissionsList(name, image, appEnabled, objV4Mgr.LocalPolicy.CurrentProfile); catch (Exception e) { Context.LogMessage(e.Message); throw new InstallException(e.Message); } } private void GetArgs() { // Obtenha os argumentos com o instalador name = this.Context.Parameters.Item["Name"]; if (name == "") throw new InstallException("No name specified"); image = this.Context.Parameters.Item["Image"]; if (image == "") throw new InstallException("No image name specified"); enabled = this.Context.Parameters.Item["Enabled"]; switch (enabled.ToUpper) { case "1": appEnabled = true; break; case "0": appEnabled = false; break; } local = this.Context.Parameters.Item["LocalSubnet"]; switch (local) { case "1": localSubnetOnly = true; break; case "0": localSubnetOnly = false; break; } }

private void AddToPermissionsList(string name, string imageName, bool enabled, INetFwV4Profile profile) { // Adicione o aplicativo à lista de permissões de ICF NetFwV4AuthorizedApplication app = new NetFwV4AuthorizedApplication(); app.Enabled = enabled; app.LocalSubnetOnly = localSubnetOnly; app.Name = name; app.ProcessImageFileName = imageName; profile.AuthorizedApplications.Add(app); }

private void RemoveFromPermissionsList(string imageName, INetFwV4Profile profile) { // Remova o aplicativo da lista de permissões de ICF profile.AuthorizedApplications.Remove(imageName); } }

Você notará que a classe herda de Installer e faz o override dos métodos Install e Uninstall da classe básica. Esses métodos serão chamados durante o processo de instalação. Ambos os métodos declaram um objeto do tipo NetFwV4MgrClass, que é usado para configurar o perfil de ICF (um objeto NetFwV4Profile) obtido por meio de uma referência à propriedade LocalPolicy.CurrentProfile. Note que, se o XPSP2 não estiver instalado na máquina de destino, o instanciamento da classe manager gerará uma exceção que será registrada (logged), o que fará com que os métodos retornem sem executar nenhuma outra ação.

O método Install chama o método privado AddToPermissionsList que aceita o nome amigável (friendly name), o nome de imagem (image name), e os Booleanos (Booleans) que serão usados para ativar (enable) o aplicativo e determinar se ele deve se comunicar apenas através da sub-rede local. O ato de adicionar o aplicativo por si só já envolve inevitavelmente instanciar um objeto NetFwV4AuthorizedApplication, definir suas propriedades e adicioná-lo à coleção AuthorizedApplication do objeto de perfil (profile). Da mesma forma, o método Uninstall chama o método RemoveFromPermissionsList para remover o aplicativo da lista de permissões de ICF usando seu nome de imagem.

Nota: O processo de importar tipos COM para o .NET e de criar uma assembly interop cria uma classe gerenciada (managed) para cada co-classe anexada à Class. É por isso que o código gerenciado mostrado usa o tipo NetFwV4MgrClass no lugar de simplesmente NetFwV4Mgr.

7. Crie um projeto Windows Setup no Visual Studio .NET e adicione-o a mesma solução.

8. Adicione a saída ou assembly produzida pelo projeto Class Library ao Application Folder, usando o File System Editor

9. No User Interface Editor, adicione uma caixa de diálogo Checkboxes após a caixa de diálogo Welcome e antes da caixa de diálogo Installation Folder.

10. Configure as propriedades da caixa de diálogo na janela de propriedades, usando a seguinte tabela:

Propriedade Valor

BannerText Configuração ICF (Internet Connection Firewall)

BodyText Este aplicativo aceita solicitações de rede de entrada. Para fazer isso, ele precisa receber permissões no Internet Connection Firewall se o seu computador estiver executando Windows XP Service Pack 2.

CheckBox1Label Permite que este aplicativo aceite solicitações de entrada de rede.

CheckBox1Property CHECKBOXA1

CheckBox1Value Não marcado

CheckBox1Visible True

CheckBox1Label Permite comunicação apenas na sub-rede local

CheckBox1Property CHECKBOXA2

CheckBox1Value Marcado

CheckBox1Visible True

Tabela 3: Propriedades da caixa de diálogo

11. Defina as checkboxes remanescentes como invisíveis (invisible)

12. No Custom Actions Editor, clique com o botão direito e adicione uma ação personalizada (custom action). Selecione a saída de projeto (project output) da assembly da class library ou a assembly propriamente dita que você adicionou anteriormente ao projeto. Clique em Ok. Isso adiciona ações para cada um dos quatro eventos, conforme mostrado abaixo. Veja a Figura 6.

Figura 6: Ações para eventos.

13. Na janela Properties, defina a propriedade CustomActionData de cada uma das ações para a string:

/Name="My Custom App" /Image="[TARGETDIR] myapp.exe" /Enabled="[CHECKBOXA1]" /LocalSubnet="[CHECKBOXA2]"

Nota: Os quatro argumentos são lidos no método private GetArgs da classe installer anteriormente mostrada. O projeto Installer fornece os valores para as propriedades [TARGETDIR], [CHECKBOXA1] e [CHECKBOXA2]. A classe ICFAppListInstaller usa esses valores para passar ao método AddToPermissionsList os parâmetros apropriados.

14. Crie a solução para construir tanto o projeto de instalação como o de configuração (installer e setup project).

15. Clique com o botão direito do mouse no projeto de setup e selecione Install. A instalação deve agora ser executada e a caixa de diálogo mostrada abaixo, na Figura 7, pedirá ao usuário que adicione o aplicativo à lista de permissões. Observe que se a caixa de seleção não estiver marcada, o aplicativo será adicionado à lista de permissões mas será desativado.

Figura 7: Caixa de diálogo para adicionar o aplicativo à lista de permissões.

16. Abra a janela Network Connection e, no painel esquerdo, clique em Configure Internet Connection Firewall. Selecione a guia Exceptions para visualizar as exceções, conforme mostradas na Figura 8 abaixo.

Figura 8: Exceptions

Notas

• O aplicativo precisa estar sendo executado no contexto do usuário com direitos de Administrator para que possa se auto-adicionar à lista de permissões do Windows Firewall.

• As portas serão automaticamente abertas e fechadas para os aplicativos na lista de permissões do Windows Firewall, independentemente do contexto de usuário no qual os aplicativos estiverem rodando.

• Os aplicativos precisam obter o consentimento do usuário antes de se auto-adicionarem à coleção AuthorizedApplications.

• Svchost.exe não pode ser adicionado à coleção AuthorizedApplications.

Exemplos

• Usando áudio e vídeo no MSN Messenger ou no Windows Messenger

• Transferindo arquivos no MSN Messenger ou no Windows Messenger

• Hospedando um jogo de vários participantes

• Usando Remote Assistance

Conexões de entrada IPv4 para serviços (IPv4 inbound connections for services)

Descrição

Embora os desenvolvedores sejam cautelosos em usar as APIs AuthorizedApplication para todos os outros cenários, o uso da API Global Port do Windows Firewall é recomendado para serviços que escutam em portas fixas. Como essas portas estarão sempre abertas, não há muita vantagem em abri-las dinamicamente. Em vez disso, os usuários ganham a capacidade de personalizar as configurações do firewall para essas portas fixas quando as APIs Global Port são usadas.

Ação exigida

Quando um serviço precisa escutar em uma porta fixa, ele precisa também perguntar ao usuário se pode permitir o serviço em abrir as portas no firewall.

Se o usuário consentir, o serviço poderá usar a interface COM INetFwV4OpenPort para adicionar regras ao perfil do Windows Firewall, usando a coleção GloballyOpenPorts para abrir a porta fixa ou portas exigidas pelo serviço. Essas regras deverão estar ativadas.

Se o usuário não consentir, o serviço ainda deverá usar a interface COM INetFwV4OpenPort para adicionar regras ao Windows Firewall para abrir a porta fixa ou as portas exigidas pelo serviço. Essas regras, entretanto, não deverão estar ativadas, para que um administrador possa facilmente ativá-las posteriormente.

Quando você usar a interface INetFwV4OpenPort para adicionar uma abertura de porta ao Windows Firewall, serão necessários os seguintes valores:

• Port. Este é o número da porta a ser aberta. Ele deve estar entre 1 e 65.536, inclusive.

• Friendly Name. Este é o nome da abertura de porta que será mostrado aos usuários na interface de usuário do Windows Firewall.

Estes são os valores opcionais:

• Protocol. Este valor é usado para especificar se a porta a ser aberta é TCP ou UDP. Caso não seja especificado, será presumido TCP.

• Local Subnet Only. Por padrão, todo o tráfego da rede é autorizado quando a porta está aberta. Este valor pode ser usado para restringir a porta, para que somente o tráfego da sub-rede local seja autorizado através do Windows Firewall. Ao abrir uma porta, o serviço deve restringir a porta ao tráfego da sub-rede local, sempre que possível.

• Enabled. Por padrão, a abertura de porta é ativada assim que ela é adicionada. Conforme descrito acima, se o usuário não consentir na abertura de portas do serviço, esse valor deve ser usado para adicionar a abertura de porta como Disabled. Isso permitirá que o usuário veja o serviço na interface de usuário do Windows Firewall e o ative mais tarde.

Quando um serviço é desativado, ele deve novamente usar a interface INetFwV4OpenPort para fechar as portas estáticas que abriu (sempre que possível). Isso pode ser feito facilmente se for o único serviço que usa as portas. No entanto, se o serviço compartilhar as portas com outros serviços, ele não deverá fechá-las a não ser que possa confirmar que elas não estejam sendo usadas por nenhum dos outros serviços.

Código de exemplo

Como um exemplo do uso dessa funcionalidade, considere os dois métodos mostrados na listagem de código abaixo. Esses métodos seriam incluídos em um assembly de class library ou dentro de um aplicativo, e exigiriam que a biblioteca de tipos COM NetFwV4TypeLib fosse referenciada no projeto.

[VB .NET] Private Function AddPort(ByVal enabled As Boolean, ByVal localOnly As Boolean, _ ByVal name As String, ByVal port As Integer, _ ByVal protocol As NET_FWV4_IP_PROTOCOL_) As Boolean ' Adicione a porta à lista de permissões de ICF Dim icfMgr As NetFwV4MgrClass Try icfMgr = New NetFwV4MgrClass Catch ex As Exception ' XPSP2 não instalado Return False End Try Try Dim profile As INetFwV4Profile Dim portClass As New NetFwV4OpenPortClass ' Obtenha o perfil atual profile = icfMgr.LocalPolicy.CurrentProfile ' Defina as propriedades de porta portClass.Enabled = enabled portClass.LocalSubnetOnly = localOnly portClass.Name = name portClass.Port = port portClass.Protocol = protocol ' Adicione a porta à lista de permissões de ICF profile.GloballyOpenPorts.Add(portClass) Return True Catch ex As Exception ' Registre o erro ou avise o usuário Return False End Try End Function Private Function RemovePort(ByVal port As Integer, _ ByVal protocol As NET_FWV4_IP_PROTOCOL_) As Boolean ' Remova a porta de acordo com a lista de permissões de ICF Dim icfMgr As NetFwV4MgrClass Try icfMgr = New NetFwV4MgrClass Catch ex As Exception ' XPSP2 não instalado Return False End Try Try Dim profile As INetFwV4Profile ' Obtenha o perfil atual profile = icfMgr.LocalPolicy.CurrentProfile ' Remova a porta de acordo com a lista de permissões de ICF profile.GloballyOpenPorts.Remove(port, protocol) Return True Catch ex As Exception ' Registre o erro ou avise o usuário Return False End Try End Function [C#]

private bool AddPort(bool enabled, bool localOnly, string name, int port, NET_FWV4_IP_PROTOCOL_ protocol) { // Adicione a porta à lista de permissões de ICF NetFwV4MgrClass icfMgr = null; try { icfMgr = new NetFwV4MgrClass(); } catch (Exception ex) { // XPSP2 não instalado return false; } try { INetFwV4Profile profile; NetFwV4OpenPortClass portClass = new NetFwV4OpenPortClass(); // Obtenha o perfil atual profile = icfMgr.LocalPolicy.CurrentProfile; // Defina as propriedades de porta portClass.Enabled = enabled; portClass.LocalSubnetOnly = localOnly; portClass.Name = name; portClass.Port = port; portClass.Protocol = protocol; // Adicione a porta à lista de permissões de ICF profile.GloballyOpenPorts.Add(portClass); return true; catch (Exception ex) { // Registre o erro ou avise o usuário return false; } }

private bool RemovePort(int port, NET_FWV4_IP_PROTOCOL_ protocol) { // Remova a porta de acordo com a lista de permissões de ICF NetFwV4MgrClass icfMgr = null; try { icfMgr = new NetFwV4MgrClass(); } catch (Exception ex) { // XPSP2 não instalado return false; } try { INetFwV4Profile profile; // Obtenha o perfil atual profile = icfMgr.LocalPolicy.CurrentProfile; // Remova a porta de acordo com a lista de permissões de ICF

profile.GloballyOpenPorts.Remove(port, protocol); return true; } catch (Exception ex) { // Registre o erro ou avise o usuário return false; } }

O método AddPort aceita os argumentos que podem ser usados para adicionar uma porta à lista de permissões de ICF. Observe que o objeto NetFwV4MgrClass é usado para obter o perfil atual e irá gerar uma exceção se o XPSP2 não estiver instalado na máquina. O objeto NetFwV4OpenPortClass é então instanciado e suas propriedades são preenchidas com os argumentos. O objeto é então adicionado à coleção GloballyOpenPorts do perfil. O método RemovePort é mais simples, já que só precisa passar a porta e o protocolo para o método Remove da coleção GloballyOpenPorts.

Um aplicativo pode usar o método AddPort conforme mostrado aqui.

[VB .NET] If MessageBox.Show( _ "Would you like to allow this application to listen on a fixed port?", _ "ICF Configuration", MessageBoxButtons.YesNo, MessageBoxIcon.Question, _ MessageBoxDefaultButton.Button2) = DialogResult.Yes Then If Not AddPort(True, False, "MyCustomPort", 3283, _ NET_FWV4_IP_PROTOCOL_.NET_FWV4_IP_PROTOCOL_TCP) Then MessageBox.Show( _ "The port could not be added. See the error log for details", _ "ICF Configuration", MessageBoxButtons.OK, MessageBoxIcon.Error) End If End If [C#] if (MessageBox.Show( "Would you like to allow this application to listen on a fixed port?", "ICF Configuration", MessageBoxButtons.YesNo, MessageBoxIcon.Question, MessageBoxDefaultButton.Button2) == DialogResult.Yes) { if (!AddPort(true, false, "MyCustomPort", 3283, NET_FWV4_IP_PROTOCOL_.NET_FWV4_IP_PROTOCOL_TCP)) MessageBox.Show( "The port could not be added. See the error log for details", "ICF Configuration", MessageBoxButtons.OK, MessageBoxIcon.Error); }

Uma vez executado, o aplicativo emitirá um prompt de confirmação ao usuário (veja a Figura 9).

Figura 9: Prompt de usuário.

Adicione a porta conforme indicado na caixa de diálogo. A Figura 10 exibe as informações.

Figura 10: Adicionando a porta para exceções.

Notas

• O aplicativo precisa estar sendo executado no contexto do usuário com direitos de Administrator para que possa abrir portas estaticamente no Windows Firewall.

• Ao abrir estaticamente as portas através da API INetFwV4, o serviço deve se limitar ao tráfego da sub-rede local, sempre que possível.

• Os serviços precisam obter o consentimento do usuário antes de abrir as portas estaticamente no Windows Firewall.

• O serviço não deve nunca abrir as portas automaticamente sem primeiro avisar o usuário.

• Quando o compartilhamento de arquivos e de impressora for ativado, quatro portas serão especificamente afetadas pela restrição de sub-rede local. As seguintes portas receberão tráfego apenas da sub-rede local.

o UDP porta 137

o UDP porta 138

o TCP porta 139

o TCP porta 445

• Se um aplicativo ou serviço também usar essas portas, ele só poderá se comunicar com outros nós na sub-rede local.

Exemplos

• Compartilhamento de arquivos e de impressora

• UpnP (Universal Plug and Play)

• Desktop remoto

Conexões de entrada IPv4 em portas RPC e DCOM (IPv4 inbound connections on RPC and DCOM ports)

Descrição

Alguns aplicativos e serviços exigem o uso de portas RPC seja através de DCOM ou de RPC para conexões de entrada. Devido aos impactos significativos na segurança resultantes da abertura de portas RPC, essas portas são tratadas como um caso especial, e os desenvolvedores só deverão tentar ativar o RPC pelo Windows Firewall quando for absolutamente necessário.

Ação exigida

O Windows Firewall inclui uma configuração explícita no firewall para ativar a abertura e o fechamento automáticos das portas para o RPC de cada perfil. Sendo assim, os aplicativos e serviços não precisam abrir portas específicas para usar o RPC para conexões de entrada. No entanto, por padrão o RPC será bloqueado pelo Windows Firewall. Isso significa que um aplicativo ou serviço precisa autorizar as portas RPC no Windows Firewall durante o processo de instalação.

É possível que alguns aplicativos mais antigos precisem ser configurados manualmente.

Se as portas RPC já estiverem autorizadas, o aplicativo ou serviço não precisará fazer nada para funcionar corretamente.

Se o usuário consentir na autorização de portas RPC, o aplicativo ou serviço deverá usar a interface COM INetFwV4Profile para definir AllowRpcPorts como TRUE, a fim de autorizar o tráfego sobre as portas RPC.

Se o usuário não concordar com a autorização para portas RPC, o aplicativo ou serviço não deverá configurar o Windows Firewall para o uso de portas RPC.

Código de exemplo

Como um exemplo da definição dessa propriedade, considere o método mostrado na listagem de código abaixo. O método SetAllowRpc aceita um valor booleano e o utiliza para definir a propriedade AllowRpcPorts do perfil ICF corrente. Repare que este fragmento de código presume que NetFwV4TypeLib tenha sido referenciado no projeto VS .NET e na assembly interop criada.

[VB .NET] Private Function SetAllowRpc(ByVal enabled As Boolean) As Boolean ' Defina AllowRpcPorts Dim objV4Mgr As NetFwV4MgrClass Try

objV4Mgr = New NetFwV4MgrClass Catch ex As Exception ' XPSP2 não instalado Return False End Try objV4Mgr.LocalPolicy.CurrentProfile.AllowRpcPorts = enabled Return True End Function

[C#] private bool SetAllowRpc(bool enabled) { // Defina AllowRpcPorts NetFwV4MgrClass objV4Mgr = null; try { objV4Mgr = new NetFwV4MgrClass(); } Catch (Exception ex) { // XPSP2 não instalado return false; } objV4Mgr.LocalPolicy.CurrentProfile.AllowRpcPorts = enabled; return true; }

Notas

É necessário que o aplicativo ou serviço esteja rodando no contexto de um usuário com direitos de Administrator para que se possa ativar ou desativar a abertura automática de portas RPC no Windows Firewall.

O aplicativo ou serviço deverá obter o consentimento do usuário antes de autorizar o uso de portas RPC no Windows Firewall.

O aplicativo ou serviço só deve tentar autorizar as portas RPC através do Windows Firewall quando for absolutamente necessário.

A definição das portas RPC só funcionará para servidores RPC que rodem no contexto de sistema local (Local System), serviço de rede (Network Service) ou de serviço local (Local Service). Portas abertas por servidores RPC que sejam executados em outros contextos de usuário não serão ativadas por meio dessa configuração. Em vez disso, esses servidores RPC devem usar a lista de permissões do Windows Firewall.

Restrições da interface RPC Foram feitas várias alterações no serviço RPC (Remote Procedure Call) do Windows XP Service Pack 2 que ajudam a tornar as interfaces RPC mais seguras por padrão bem como reduzem o risco de ataques de superfície do Windows XP. A mudança mais significativa consiste na inclusão da chave de registro RestrictRemoteClients . Essa chave modifica o comportamento de todas as interfaces RPC no sistema e visa, por padrão, eliminar acessos anônimos remotos às interfaces RPC do sistema, com algumas exceções. A mudanças adicionais incluem a chave de registro EnableAuthEpResolution e três novas flags de registro de interface.

Com essa nova funcionalidade no Service Pack 2, é muito mais difícil atacar um computador através de uma interface RPC, já que a autenticação simples é obrigatória por padrão. Esse é um alívio particularmente útil

contra worms que contam com buffer overruns exploráveis que podem ser chamadas remotamente através de conexões anônimas.

RestrictRemoteClients Chave de registro RestrictRemoteClients (\\HKLM\SOFTWARE\Policies\Microsoft\Windows NT\RPC\)

Quando uma interface é registrada por meio da API RpcServerRegisterIfExor RpcServerRegisterIf2, o RPC permite que o aplicativo do servidor restrinja o acesso à interface, geralmente através de uma callback de segurança. A chave de registro RestrictRemoteClients força o RPC a realizar verificações adicionais de segurança para todas as interfaces, mesmo que a interface não possua nenhuma callback de segurança registrada.

A chave de registro RestrictRemoteClients pode ter os três valores descritos abaixo. Se a chave não estiver presente, é equivalente a ter o valor RPC_ Restrict_Remote_Client_Default.

• O valor RPC_RESTRICT_REMOTE_CLIENT_NONE (0) faz com que o sistema ignore a nova restrição à interface RPC. O aplicativo do servidor é totalmente responsável por impor as restrições de RPC apropriadas. Essa configuração é equivalente ao comportamento nas versões anteriores do Windows.

• O valor RPC_RESTRICT_REMOTE_CLIENT_DEFAULT (1) é o valor padrão no Windows XP Service Pack 2. Esse valor restringe o acesso a todas as interfaces RPC. Todas as chamadas anônimas remotas são rejeitadas pelo runtime do RPC. Se uma interface registra uma callback de segurança e fornece o sinalizador (flag) RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH, essa restrição não se aplicará a ela.

• O valor RPC_RESTRICT_REMOTE_CLIENT_HIGH (2) é o mesmo que o valor RPC_RESTRICT_REMOTE_CLIENT_DEFAULT; a diferença é que o sinalizador RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH não fará com que a interface seja dispensada da restrição. Com esse valor, um sistema não pode receber chamadas anônimas remotas usando o RPC.

RestrictRemoteClients – Implicações para o desenvolvedor Descrição

Se o aplicativo RPC espera receber chamadas de clientes RPC anônimos remotos, essa mudança poderá quebrar a aplicação.

Ação exigida

Existem três opções para reparar esses problemas. Elas estão listadas por ordem de preferência.

• Exija que seus clientes RPC usem segurança do RPC quando contatarem o aplicativo servidor. Esse é o melhor método de reduzir ameaças de segurança.

• Faça com que sua interface seja dispensada de requerer autenticação, definindo a flag RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH durante o registro da interface por meio de RpcServerRegisterIf2 ou de RpcServerRegisterIfEx. Isso configura o RPC para autorizar conexões anônimas apenas para a interface de seu aplicativo.

• Obrigue o RPC a exibir o mesmo comportamento das versões anteriores do Windows definindo a chave de registro RestrictRemoteClients como RPC_RESTRICT_REMOTE_CLIENT_NONE (0). O RPC irá então aceitar conexões anônimas para todas as interfaces. Essa opção deverá ser evitada sempre que possível, já que reduz a segurança geral do computador.

Notas

• Os clients RPC que usam a seqüência de protocolo named pipe (ncacn_np) estão isentos de todas as restrições discutidas nesta seção. Devido aos diversos e significativos problemas de compatibilidade retroativa, não é possível restringir a seqüência de protocolo named pipe por padrão.

EnableAuthEpResolution Chave de registro EnableAuthEpResolution (\\HKLM\SOFTWARE\Policies\Microsoft\Windows NT\RPC)

Uma interface RPC que seja remotamente e anonimamente acessível e que seja registrada por padrão no Windows XP apresenta uma superfície de ataque significativa. O RPC propriamente dito precisa registrar essa interface para fornecer uma resolução de endpoint (endpoint resolution) para as chamadas que usam endpoints dinâmicos.

Com a inclusão da chave de registro RestrictRemoteClients, por padrão, a interface RPC Endpoint Mapper não pode ser acessada anonimamente. Essa é uma melhoria de segurança significativa, mas ela muda o processo de solução de um endpoint. Atualmente, qualquer cliente RPC que tente fazer uma chamada usando um endpoint dinâmico deverá primeiro consultar o RPC Endpoint Mapper no servidor para determinar à qual endpoint ele deve se conectar. Essa consulta é realizada anonimamente, mesmo que o cliente RPC propriamente dito seja executado com segurança RPC.

As chamadas anônimas para a interface RPC Endpoint Mapper falharão por padrão no Windows XP Service Pack 2 devido ao valor padrão da nova chave RestrictRemoteClients. Isso torna necessário modificar o runtime do cliente RPC para executar uma consulta autenticada ao Endpoint Mapper. Se a chave EnableAuthEpResolution estiver definida no cliente, o runtime do cliente RPC usará o NTLM para autenticar o Endpoint Mapper. Essa consulta autenticada só será realizada se a chamada do cliente RPC real usar autenticação.

EnableAuthEpResolution – Implicações para o desenvolvedor Descrição

Essa alteração é exigida para habilitar um cliente RPC a fazer uma chamada para um servidor RPC que tenha registrado um endpoint dinâmico em um sistema Windows XP Service Pack 2. O computador cliente precisa definir esta chave de registro para que possa executar uma consulta autenticada ao RPC Endpoint Mapper.

Essa chave não quebra nada. Ela é usada para ativar o cenário específico descrito mais cedo. Quando essa chave é ativada, todas as consultas ao RPC Endpoint Mapper que forem realizadas em favor das chamadas de autenticação serão realizadas por meio de autenticação NTLM.

Ação exigida

Nenhuma. Consulte a descrição acima.

Novas flags de registro de interface RPC (RPC Interface Registration Flags) Foram criadas três novas flags de registro de interface, que facilitam ao desenvolvedor de aplicativo proteger a interface RPC.

• RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH Quando essa flag estiver registrada, o runtime do RPC invocará o callback de segurança registrada para todas as chamadas, independentemente de todas as configurações de segurança da chamada. Sem essa flag, o RPC rejeitará todas as chamadas não autenticadas antes de elas alcançarem o callback de segurança. Essa flag só funcionará quando houver um callback de segurança registrado.

• RPC_IF_SEC_NO_CACHE Um callback de segurança é registrado para uma interface de modo a restringir o acesso a ela. Um callback de segurança típico personifica (impersonates) o cliente para determinar se ele possui direitos suficientes para fazer uma chamada para a interface. Se a identidade de um cliente em particular passar um callback de segurança uma vez, ela geralmente passará o mesmo callback de segurança todas as outras vezes. O runtime do RPC tira proveito desse padrão lembrando-se de quando a identidade de um cliente individual passou um callback de segurança e ignora o callback de segurança das chamadas subseqüentes feitas por esse cliente para a mesma interface. Esse recurso é chamado security callback caching e existe desde o Windows 2000. No caso do Windows XP Service Pack 2, você pode usar a flag RPC_IF_ SEC _NO_CACHE para desativar o caching do callback de segurança para uma determinada interface. Isso é útil no caso da verificação de segurança precisar mudar, possivelmente rejeitando uma identidade de cliente que tenha sido anteriormente autorizada.

• RPC_IF_LOCAL_ONLY Quando uma interface é registrada com essa flag, o RPC rejeita as chamadas feitas pelos clientes RPC remotos. Além disso, as chamadas locais feitas sobre todas as seqüências de protocolo ncadg_* e ncacn_* (exceto para named pipes, usando ncacn_np) também serão rejeitadas. Se uma chamada for feita em ncacn_np, o RPC só a autorizará se ela não vier do SVR, que filtra todas as chamadas remotas. As chamadas Ncalrpc são sempre autorizadas.

Novas flags de registro de interface do RPC – Implicações para o desenvolvedor Implicações para o desenvolvedor

Essa mudança oferece aos desenvolvedores de aplicativos RPC ferramentas de segurança adicionais para ajudá-los a proteger melhor sua interface RPC.

Essas flags não alterarão nem quebrarão nenhum aplicativo Windows XP existente. Seu uso ficará a critério do desenvolvedor.

Aprimoramentos de segurança no DCOM O COM (Component Object Model) da Microsoft é um sistema orientado a objetos, distribuído e independente de plataforma, destinado à criação de componentes de software binários que podem interagir entre si. O DCOM (Distributed Component Object Model) permite que os aplicativos sejam distribuídos entre os locais mais relevantes a você e ao aplicativo. O protocolo de conexão DCOM oferece suporte de forma transparente, visando à comunicação confiável e eficiente entre os componentes COM.

Se você só fizer uso do COM para os componentes COM in-process, esta seção não se aplicará ao seu caso.

Esse recurso só será indicado ao seu caso se você tiver um aplicativo servidor COM que atenda a um dos seguintes critérios:

• A permissão de acesso do aplicativo é menos rígida do que a necessária para executá-lo.

• Geralmente, o aplicativo é ativado em um computador que execute Microsoft Windows XP por um cliente COM remoto, sem o uso de uma conta administrativa.

• Por padrão, o aplicativo usa callbacks remotos não autenticados em um computador que execute Windows XP.

• O aplicativo só se destina ao uso local. Isso significa que você pode restringir o seu aplicativo servidor COM para que ele não possa ser acessado remotamente.

Várias mudanças foram feitas no COM. Para saber mais, clique no item de seu interesse

• Computer-wide Restrictions

• Granular COM Permissions

Restrições no âmbito do computador (Computer-wide Restrictions) Foi feita uma alteração no COM para fornecer controles de acesso no âmbito do computador, os quais governam o acesso a todas as solicitações de chamada, inicialização ou ativação no computador. A maneira mais simples de considerar esses controles de acesso é como uma chamada AccessCheck adicional que é feita em relação a uma lista de controle de acesso no âmbito do computador (ACL - access control list) em cada chamada, ativação ou inicialização de qualquer servidor COM no computador. Se o AccessCheck falhar, a solicitação de chamada, ativação ou inicialização será negada. Isso ocorrerá juntamente com qualquer AccessCheck que seja executado em relação a ACLs específicas ao servidor. Como conseqüência, ele fornece uma barreira de autorização mínima que precisa ser passada para acessar os servidores COM no computador. Haverá uma ACL no âmbito do computador para inicializar permissões que abranjam ativação e inicialização, bem como uma ACL no âmbito do computador para permissões de acesso que abranjam chamadas. Elas podem ser configuradas por meio de programação ou através da console MMC (Component Services Microsoft Management Console). Para configurar essa opção a partir da interface do usuário, o administrador deve abrir o gerenciador de Component Services e selecionar Properties no menu de contexto do computador a ser configurado. Será exibida a caixa de diálogo mostrada na Figura 11, e a segurança deverá ser configurada na guia COM Security.

Figura 11: My Computer Properties, COM Security

Essas ACLs no âmbito do computador oferecem uma maneira de substituir (override) configurações de segurança fracas especificadas por um aplicativo através do CoInitializeSecurity ou de configurações de segurança específicas ao aplicativo. Isso fornece um padrão de segurança mínimo a ser passado, independentemente das configurações do servidor específico.

Essas ACLs são verificadas quando as interfaces expostas pelo RPCSS (pacote de gerenciamento de memória) são acessadas. Isso oferece um método para controlar quem tem acesso a esse serviço de sistema.

Essas ACLs disponibilizam um local centralizado, onde um administrador pode definir uma política de autorização comum que se aplique a todos os servidores COM no computador.

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

Permissão Administrador Todos AnônimoInicialização (Launch) Local (Launch)

Local Activate Remote (Launch) Remote Activate

Local (Launch) Local Activate

Acesso (Access) Local (Call) Remote (Call)

Local (Call)

Tabela 4: Configurações de restrição em computador Windows XP

Muitos aplicativos COM incluem algum código específico à segurança (por exemplo, chamar CoInitializeSecurity), mas usam configurações muito fracas, que freqüentemente permitem acesso não autorizado ao processo. Atualmente, não existe nenhuma maneira de um administrador alterar essas configurações para uma segurança mais forte nas versões anteriores do Windows.

A infra-estrutura do COM inclui o pacote de gerenciamento de memória RpcSs, um serviço de sistema que é executado durante a inicialização do sistema após ser adicionado à máquina. Ele gerencia a ativação de objetos COM e a tabela de objetos em execução, e fornece serviços auxiliares ao DCOM remoto. Ele expõe as interfaces RPC que podem ser chamadas remotamente. Como alguns dos servidores COM permitem acesso remoto não autenticado (conforme explicado na seção anterior), essas interfaces podem ser chamadas por qualquer pessoa, inclusive por usuários não autenticados. Como resultado, os RpcSs podem ser atacados por qualquer usuário mal-intencionado, através de computadores remotos não autenticados.

Nas versões anteriores do Windows, não havia nenhuma maneira de o administrador compreender o nível de exposição dos servidores COM em um computador. Para ter uma idéia do nível de exposição, o administrador precisava verificar sistematicamente as opções de segurança configuradas para todos os aplicativos COM registrados no computador, mas, como existem aproximadamente 150 servidores COM em uma instalação padrão do Windows XP, essa tarefa é desencorajadora. Não existe nenhuma maneira de ver as configurações de um servidor que incorpore segurança no software, exceto revendo o código-fonte daquele software.

As restrições no âmbito do computador do DCOM minimizam esses três problemas. Elas também permitem que o administrador desative a ativação, a inicialização e as chamadas DCOM de entrada.

Restrições no âmbito do computador – implicações para o desenvolvedor Descrição

Por padrão, qualquer pessoa, através de um grupo Todos (Everyone), recebe permissões para inicialização local, ativação local e chamadas locais. Isso deveria permitir que todos os cenários locais funcionassem sem modificação no software ou no sistema operacional.

Por padrão, todos recebem permissões de chamada remota. Isso permite muitos cenários de clientes COM, inclusive o caso comum onde um cliente COM passa uma referência local a um servidor remoto, transformando um cliente em um servidor. Isso talvez desabilite cenários que requeiram chamadas remotas não autenticadas.

Da mesma forma, por padrão, somente os administradores recebem permissões de inicialização e ativação remotas. Isso inabilita ativações remotas por parte de não-administradores nos servidores COM instalados.

Ação exigida

Como resultado, se você implementar um servidor COM e esperar oferecer suporte à ativação remota por parte de um cliente COM não administrativo, ou esperar oferecer suporte a chamadas não autenticadas remotas, é melhor reavaliar se essa é a melhor configuração. Nesse caso, você precisará alterar a configuração padrão desse recurso.

Essas ACLs são armazenadas no registro (registry) em:

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

Este é um valor nomeado que é definido como um tipo REG _BINARY; ele contém dados que descrevem a ACL dos principals que podem acessar qualquer classe 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 por meio de funções de segurança normais.

Somente os usuários com direitos de Administrador poderão modificar essas configurações.

Permissões COM granulares (Granular COM Permissions) Essa alteração diferencia os direitos de acesso do COM com base no espaço. Os dois espaços definidos são Local e Remote. Uma mensagem COM Local chega por meio do protocolo LRPC, enquanto a mensagem COM Remote chega por meio de um protocolo de transporte de host de uma RPC (remote procedure call), tais como o TCP (transmission control protocol). Por esse motivo, as permissões de chamada e de ativação estão sendo separadas para refletir os dois espaços definidos. Além disso, as permissões de ativação estão sendo movidas da Access Permission ACL para a Launch Permission ACL. Como a ativação e a inicialização estão ambas relacionadas com a obtenção de um ponteiro de interface, os direitos de acesso de inicialização e ativação logicamente devem ficar juntos em uma ACL. E, como você sempre especifica permissões de inicialização através de configuração (se comparado às permissões de acesso (Access Permissions), que são freqüentemente especificadas por programação), colocar a permissão de ativação na Launch Permission ACL dará ao administrador controle sobre a ativação.

As Launch Permission ACLs são divididas em quatro direitos de acesso:

• Local Launch (LL)

• Remote Launch (RL)

• Local Activate (LA)

• Remote Activate (RA)

O descritor de segurança de permissões de acesso (Access Permission security descriptor) está dividido em dois tipos de direitos de acesso:

• Local Calls (LC)

• Remote Calls (RC)

Essa segurança COM permite que o administrador aplique configurações de segurança bastante específicas. Por exemplo, você pode configurar um servidor COM para que ele aceite chamadas locais de qualquer pessoa mas só aceite chamadas remotas dos administradores. A interface de usuário para configurar essas opções de segurança específicas é mostrada na Figura 12.

Figura 12: Opções de segurança para objetos COM

Depois que o administrador selecionar Customize em Launch and Activate Permissions, bastará clicar no botão Edit para exibir a caixa de diálogo mostrada na Figura 13.

Figura 13: Caixa de diálogo Launch Permissions

Essas distinções podem ser especificadas através de alterações nos descritores de segurança de permissões do COM.

As versões mais antigas do aplicativo servidor COM não têm como restringir um aplicativo para que ele só possa ser usado localmente sem ser exposto na rede por meio do DCOM . Quando os usuários têm acesso a um aplicativo servidor COM, eles têm acesso tanto ao uso local como remoto.

Um aplicativo servidor COM pode querer se expor a usuários não autenticados para implementar um cenário de callback do COM. Neste cenário, o aplicativo deve expor também sua ativação aos usuários não autenticados, o que pode não ser desejado.

Permissões COM precisas dão ao administrador flexibilidade para controlar a política de permissão COM do computador. Essas permissões habilitam a segurança para os cenários especificados.

Como resultado, a Tabela 5 mostrada abaixo representa as configurações que foram adicionadas ou alteradas no Windows XP Service Pack 2.

Nome da configuração Localização Valor padrão anterior (se aplicável)

Valor padrão Valores possíveis

MachineLaunchRestriction HKLM\SOFTWARE\ Microsoft\Ole\

Everyone = LL,LA,RL,RA Anonymous = LL,LA,RL,RA (Esta é uma nova chave de registro. Com base no comportamento existente, esses serão os valores efetivos.)

Administrator = LL,LA,RL,RA Everyone = LL,LA

ACL

MachineAccessRestriction HKLM\SOFTWARE\ Microsoft\Ole\

Everyone = LC, RC Anonymous = LC, RC (Esta é uma nova chave de registro. Com base no comportamento existente, esses serão os valores efetivos.)

Everyone = Local, Remote. Anonymous = Local

ACL

ActivationFailureLoggingLevel HKLM\SOFTWARE\ Microsoft\Ole\

0 0 0-2

CallFailureLoggingLevel HKLM\SOFTWARE\ Microsoft\Ole\

N/A 2 1,2

InvalidSecurityDescriptor LoggingLevel

HKLM\SOFTWARE\ Microsoft\Ole\

N/A 1 1,2

Tabela 5: Inclusões e/ou alterações no Windows XP Service Pack 2

Permissões COM granulares – Implicações para o desenvolvedor

A inclusão de mais permissões granulares para o servidor COM traz várias implicações para os desenvolvedores com relação à compatibilidade retroativa.

Descrição

Para oferecer compatibilidade retroativa, os descritores de segurança do COM existentes são interpretados para autorizar ou negar acesso local e remoto simultaneamente. Ou seja, uma entrada de controle de acesso (ACE - access control entry) irá autorizar o acesso local e remoto ou negá-los.

Não existem problemas de compatibilidade retroativa com relação a direitos de inicialização ou de chamadas. Existem, no entanto, problemas de compatibilidade com relação aos 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 do que o mínimo necessário para os cenários de ativação do cliente, então a Launch Permissions ACL deverá ser modificada para que forneça as permissões apropriadas aos clientes autorizados.

No caso de aplicativos COM que utilizam as opções de segurança padrão, não há problemas de compatibilidade. No caso de aplicativos iniciados dinamicamente por meio da ativação COM, a maioria não terá problemas de compatibilidade, já que as permissões de inicialização já deverão incluir qualquer um que seja capaz de ativar um objeto. Se essas permissões não estiverem configuradas corretamente, poderá haver falhas de ativação aleatórias quando os chamadores sem permissão de ativação tentarem ativar um objeto quando o servidor COM não estiver em execução.

Os aplicativos que merecem mais atenção com relação a problemas de compatibilidade são os aplicativos COM que já tiverem sido inicializados por meio de outro mecanismo, como o Windows Explorer ou o Service Control Manager. Você também pode iniciar esses aplicativos por meio de uma ativação COM anterior, que substitui as permissões de inicialização de acesso padrão e especifica as permissões de inicialização que forem mais restritivas do que as permissões de chamada.

Se um sistema que foi atualizado para o Windows XP Service Pack 2 for retornado a um service pack mais antigo, qualquer entrada de controle de acesso que tenha sido editada para permitir acesso local, acesso remoto, ou ambos, será interpretada para autorizar acesso local e remoto. Qualquer ACE que tenha sido editada para negar acesso local, acesso remoto, ou ambos, será interpretada para negar tanto acesso local como remoto. Você deve assegurar que todos as ACEs sejam verificadas sempre que for desinstalar um service pack.

Ação exigida

Se você implementar um servidor COM e substituir as configurações de segurança padrão, assegure-se de que a Launch Permissions ACL específica ao aplicativo conceda permissão de ativação aos usuários apropriados. Se ela não conceder, você precisará alterar a permissão de inicialização específica ao aplicativo para dar os direitos de ativação aos usuários apropriados. As permissões de inicialização específicas ao aplicativo são armazenadas no registro. Para obter mais informações, consulte http://go.microsoft.com/fwlink/?LinkId=20924.

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

Nova proteção de memória Com o Windows XP Service Pack 2, a Microsoft está introduzindo proteção de execução (Execution Protection) para dar mais proteção contra o mau uso do espaço de memória.

Leia mais sobre Execution Protection

Proteção de execução (Execution Protection) A proteção de execução (também conhecida como NX, ou no execute) impede a execução do código a partir de páginas de dados, tais como a heap padrão, diversas pilhas e pools de memória. A proteção pode ser aplicada tanto no modo usuário como no modo kernel.

Ela também força os desenvolvedores a marcar explicitamente as páginas como executáveis antes de executar o código das páginas de dados. Isso promove boa engenharia de software e melhores práticas para os desenvolvedores de aplicativos e drivers.

A proteção de execução consiste em um recurso do sistema operacional que conta com o hardware do processador para marcar a memória com um atributo que indique que o código não deve ser executado a partir daquela memória. A proteção de execução funciona com base na página de memória virtual, muito freqüentemente alterando um bit na entrada da tabela da página (PTE) para marcar a página de memória.

A implementação da proteção de execução no hardware, bem como a marcação da página de memória virtual, variam de acordo com a arquitetura do processador. No entanto, os processadores que oferecem suporte à proteção de execução são capazes de gerar uma exceção quando o código for executado a partir de uma página marcada com o conjunto de atributos apropriado. A versão de 32 bits do Windows atualmente utiliza o recurso de processador no-execute page protections conforme definido pela AMD (Advanced Micro Devices). Esse recurso requer que o processador seja executado no modo PAE (Physical Address Extension).

Embora as únicas famílias de processadores que oferecem suporte a hardware compatível com Windows para execução de proteção sejam a AMD K8 e os processadores Itanium da Intel, espera-se que os futuros processadores de 32 e 64 bits forneçam proteção de execução. A Microsoft está se preparando para isso e encoraja essa tendência oferecendo suporte à proteção de execução em seus sistemas operacionais Windows.

Os desenvolvedores de drivers e aplicativos devem estar familiarizados com a proteção de execução e com os requisitos do software em execução na plataforma de suporte. Os aplicativos que utilizam geração de código JIT (just-in-time) ou que executam memória a partir da heap ou da pilha de processos padrão devem prestar especial atenção aos requisitos de proteção de execução (Execution Protection).

Os desenvolvedores de drivers são encorajados a conhecer o modo PAE nas plataformas que oferecem suporte à proteção de execução. O comportamento do modo PAE nos sistemas Windows com menos de 4 gigabytes (GB) de espaço de endereço físico foi alterado para minimizar as incompatibilidades de driver.

A Microsoft está oferecendo suporte a processadores emergentes que incorporam proteção de execução, por meio de acréscimos no Windows (começando pelo Microsoft Windows XP Service Pack 2). A proteção de execução tem vantagens óbvias com relação a exploração de buffer overrun e promove boas práticas de codificação gerais para desenvolvedores para Microsoft e outros desenvolvedores.

Dois tipos de funcionalidade foram adicionados neste service pack.

• Proteção de execução em versões de 64 bits do Windows As versões de 64 bits do Windows que estão alojadas em processadores de 64 bits podem executar programas de aplicativos no modo 64 bits, também chamado modo nativo. Independentemente da arquitetura do processador, a proteção de execução no modo kernel das versões de 64 bits do Windows é aplicada à pilha (stack), ao paged pool e ao session pool (pool de sessão). A proteção de execução é ativada por padrão no Windows XP Service Pack 2, e não há maneiras de desativá-la. Os aplicativos de 64 bits não devem executar código a partir da pilha ou na heap de processo padrão. Os aplicativos que desejam alocar a memória executável devem fazê-lo usando o VirtualAlloc() com um dos atributos de memória PAGE_EXECUTE.

• Proteção de execução em versões de 32 bits do Windows e aplicativos Essa funcionalidade tem dois modos.

o Proteção de execução de modo de usuário Espera-se que em breve muitos computadores que executam aplicativos Windows ou compatíveis com Windows usarão processadores de 32 bits que executem versões de 32 bits do Windows. No entanto, novos processadores como o AMD Opteron e Athlon-64 suportam ambos os modos operacionais de 32 e 64 bits (legado e nativo, respectivamente). Esses processadores combinados de 32 e 64 bits são capazes de rodar em um ambiente legado puro (sistema operacional de 32 bits com aplicativos de 32 bits) e podem usufruir da proteção de execução quando o modo PAE está habilitado. A Microsoft está estudando métodos de desativar ou ativar a proteção de execução por aplicativo (nos aplicativos de 32 bits). Os aplicativos de 64 bits devem funcionar com a proteção de execução ativada por padrão. Uma exceção na proteção de execução resultará no código de status STATUS_ACCESS_VIOLATION (0xc0000005) nos sistemas Windows. Na maioria dos processos, ela será uma exceção não tratada, que causará a interrupção do processo.

o Proteção de execução do modo Kernel A proteção de execução funciona de forma semelhante tanto no modo de usuário como no modo kernel. A proteção de execução para regiões da memória no modo kernel não poderá ser ativada ou desativada de acordo com o driver. Nas versões de 32 bits do Windows, a proteção de execução só é aplicada por padrão à pilha (stack). Observe que isso difere das versões de 64 bits do Windows, onde a pilha, o paged pool e o session pool (pool de sessão) têm a proteção de execução aplicada. Uma violação de acesso de proteção de execução no modo kernel resultará em um Bugcheck 0xFC: ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY.

Proteção de execução – Implicações para o desenvolvedor Estas alterações podem atingir duas áreas de compatibilidade que afetarão diretamente o desenvolvedor.

Compatibilidade do aplicativo

Descrição

É previsível que o comportamento de alguns aplicativos seja incompatível com a proteção de execução. Aplicativos que executam geração de código dinâmico (tais como geração de código JIT - Just-In-Time) que não marcam explicitamente o código gerado com direito de permissão Execute podem ter problemas de compatibilidade com a proteção de execução. Por exemplo, os aplicativos Windows .NET Framework atualmente não marcam o código gerado com permissões Execute. O XPSP2 reconhece as versões atuais do .NET Framework e as executa com o NX desativado (off). Desse modo, os aplicativos .NET existentes ainda continuarão a ser executados. A Microsoft está aprimorando o .NET Framework para tirar proveito do NX e fornecerá service packs para cada versão lançada no XP SP2 RTM timeframe. O .NET Framework "Whidbey" irá oferecer suporte nativo a NX.

Os desenvolvedores de aplicativo poderão encontrar aplicativos que quebram quando o NX está ativado. Se isso ocorrer, o desenvolvedor ou administrador do sistema poderá aplicar um patch, um fragmento de código que é inserido em uma pilha de chamadas ou numa cadeia de códigos. O problema geralmente ocorre em um contexto não gerenciado, e não foi previsto originalmente. O fragmento de dados é adicionado ao aplicativo por meio do ACT (Application Compatibility Toolkit). Um novo fragmento de dados, a instrução Disable NX, é incluído no ACT para desativar o Data Execution Prevention para um aplicativo, permitindo que este seja executado apropriadamente. Para obter mais informações sobre o Application Compatibility Toolkit, consulte http://www.microsoft.com/windows/appcompatibility/default.mspx.

Ação exigida

Os aplicativos que tentarem violar a proteção de execução receberão uma exceção com o código de status STATUS_ACCESS_VIOLATION (0xC0000005). Se um aplicativo necessitar de memória executável, ele deve definir explicitamente esse atributo na memória apropriada, especificando PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE ou PAGE_EXECUTE_WRITECOPY no argumento de proteção de memória das funções de alocação da memória virtual.

LPVOID VirtualAlloc( LPVOID lpAddress, SIZE_T dwSize, DWORD flAllocationType, DWORD flProtect);

Compatibilidade do driver

Descrição

Os problemas de compatibilidade de driver relacionados à proteção de execução são geralmente centrados nos problemas de compatibilidade induzida do modo PAE.

Por si só, a proteção de execução pode criar problemas de compatibilidade com drivers que executem geração de código ou que utilizem outras técnicas para gerar código executável em tempo real. O suporte à proteção de execução estará sempre ativado em drivers que são carregados em versões de 64 bits do Windows. Embora muitos drivers que criam código executável foram reparados no Windows XP Service Pack 2, não há garantia de que todos tenham sido atualizados. No entanto, como existem poucos drivers que empregam essas técnicas, não se espera que a proteção de execução sozinha causará uma grande quantidade de problemas de compatibilidade de driver.

O principal problema de compatibilidade de driver diz respeito à execução do modo PAE (Physical Address Extension) nos sistemas de 32 bits. Alguns drivers podem falhar no carregamento se o PAE estiver ativado porque o dispositivo pode não ser capaz de executar endereçamento de 64 bits ou pode assumir que o modo PAE requer mais de 4 GB de RAM. Esses drivers partem do princípio de que receberão sempre endereços de 64 bits quando no modo PAE e que eles (ou seus dispositivos) são incapazes de interpretar o endereço.

Outros drivers carregam no modo PAE mas podem causar instabilidade no sistema ao modificarem diretamente entradas de tabela de página (PTEs) do sistema. Esses drivers esperam PTEs de 32 bits, mas em vez disso, recebem PTEs de 64 bits no modo PAE.

O maior problema de compatibilidade de driver PAE envolve transferências de DMA (direct memory access) e alocação de registro de mapa. Muitos dispositivos que suportam DMA, geralmente adaptadores de 32 bits, não são capazes de executar endereçamento físico de 64 bits. Quando executado no modo 32 bits, o dispositivo pode alocar todo o espaço de endereço físico. No modo PAE, é possível que os dados estejam presentes em um endereço físico maior que 4 GB. Para permitir que os dispositivos com essas limitações funcionem neste cenário, o Windows XP Service Pack 2 fornece um buffer duplo para a transação DMA, disponibilizando um endereço de 32 bits indicado por um registro de mapa (map register). O dispositivo pode executar a transação DMA para o endereço de 32 bits, e o kernel copia a memória no endereço de 64 bits fornecido ao driver.

Quando esse sistema é executado com o PAE desativado, os drivers de dispositivos de 32 bits nunca requerem que seus registros de mapa sejam apoiados pela memória real. Isso significa que o buffer duplo não é necessário, já que todos os dispositivos e drivers estão dentro do espaço de endereço de 32 bits. Com base nos testes de drivers para dispositivos de 32 bits em computadores baseados em x86 e x64, presume-se que muitos drivers compatíveis com DMA, testados no cliente esperam registros de mapa ilimitados. Para restringir os problemas de compatibilidade, o Windows XP Service Pack 2 incluiu alterações na camada de abstração de hardware (HAL) que imitam o comportamento do 32-bit HAL DMA. A HAL alterada concede registros de mapa ilimitados quando o sistema está rodando no modo PAE. Além disso, o gerenciador de memória do kernel ignora qualquer endereço físico acima de 4 GB.

Como resultado dessas alterações na HAL e no gerenciador de memória, o impacto na compatibilidade do driver do dispositivo deverá ser mínimo nos sistemas compatíveis com NX que executem Windows XP Service Pack 2.

Ação exigida

Os aplicativos que requerem regiões executáveis de memória devem usar os atributos PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE ou PAGE_EXECUTE_WRITECOPY ao alocar a memória. Além disso, os aplicativos não podem ser executados a partir da pilha (stack) ou heap de processo padrão (default process heap). A maioria dos aplicativos que executa ações incompatíveis com a proteção de execução precisará ser atualizada para ser compatível.

Se um aplicativo alocar memória executável a partir de uma heap dedicada, ele deverá assegurar que a flag EXECUTE esteja definida na memória heap. Ele pode usar a API VirtualAlloc para alocar a memória com as configurações de proteção apropriadas. Se um aplicativo não alocar a memória executável a partir de uma heap dedicada, ele precisará ser alterado para que possa fazê-lo. O aplicativo precisará criar essa heap usando a API VirtualAlloc, e precisará ao menos especificar a flag EXECUTE para essa memória. Qualquer código gerado deverá ser colocado dentro dessa heap executável. Uma vez gerado o código executável, recomenda-se que o aplicativo defina proteções de memória para desautorizar o acesso WRITE à heap por intermédio da API VirtualProtect. Isso fornecerá proteção adicional para as regiões executáveis do espaço de endereço do processo.

LPVOID lpvBase = VirtualAlloc( NULL, // sistema seleciona endereço dwSize, // tamanho da alocação MEM_RESERVE, // alocar páginas reservadas PAGE_EXECUTE_READWRITE); // acesso Execute, Read, Write /* Altere a proteção de página para read only. */ VirtualProtect (lpStack, dwSize, PAGE_READONLY, lpdwOldProt);

Segurança de e-mail aprimorada As pessoas compartilham informações e colaboram entre si trocando arquivos em seus computadores. Elas enviam arquivos por e-mail, na forma de anexos. Além disso, transferem arquivos através de clientes de bate-papo (chat) em tempo real e baixam arquivos na Internet. Com o uso cada vez maior das redes em banda larga, as pessoas têm ainda mais facilidade para trocar arquivos. Infelizmente, os hackers utilizam esses mesmos mecanismos para fazer com que seus softwares mal-intencionados se proliferem com rapidez. Eles enganam os usuários, colocando cargas malignas em arquivos benignos (como vírus de macros) ou anexando arquivos infectados a mensagens de e-mail.

Para aumentar a proteção de usuário, muitos aplicativos bloqueiam tipos de arquivo "perigosos" específicos, usando um esquema personalizado ou recorrendo à API AssocIsDangerous fornecida no Windows XP Service Pack 1 ou no Windows Server 2003, e emitem avisos poderosos para os tipos de arquivos considerados menos perigosos.

Esse modelo de comportamento oferece vários problemas. Primeiro, os usuários são obrigados a tomar decisões de confiabilidade em relação aos anexos, o que abre a probabilidade de eles falharem ao fazer distinção entre vírus e anexos seguros. Isso acontece porque os usuários tomam decisões de confiabilidade com base em convenções sociais, em vez de por compreensão técnica. Em segundo lugar, é impossível criar uma lista completa de todos os tipos de arquivo e classificá-los de forma precisa com segurança, porque a extensão nem sempre é o determinante final do tipo (como nos documentos XML ou MIME sniffing) e porque este é um modelo inerentemente reagente, em vez de adaptativo (o que torna ainda mais importante evitar esse tipo de modelo como um parâmetro de decisão final). Terceiro, embora o modelo de força bruta ofereça alguma proteção (porque limita os tipos de arquivos que podem ser trocados), ele também limita a utilidade

do Windows. Por fim, atualmente não existe nenhuma relação de confiança explícita com aplicativos que processam arquivos baixados (manipuladores de arquivos). Mesmo que um tipo de arquivo não execute código explicitamente (como JPG ou ZIP), ele ainda pode ser não confiável devido a bugs ou ao comportamento dos manipuladores. É necessário haver uma relação de confiança estabelecida com os manipuladores para determinar o quanto eles são confiáveis e atualizados.

Para solucionar esses problemas, o Windows XP Service Pack 2 incluiu o Attachment Execute Service, cuja meta geral é fornecer aos usuários uma maneira de trocar arquivos com segurança. A Microsoft criou o Attachment Execution Services porque os desenvolvedores precisam habilitar os usuários a enviar e receber anexos sem preocupação. Com o Attachment Execution Services, o sistema se protege e ao usuário, emitindo a ele decisões de confiabilidade apenas em cenários de baixo risco. Embora os vírus de anexo sejam epidêmicos, ainda há pouca ajuda para os desenvolvedores escreverem recursos de anexos seguros. Mesmo quando os desenvolvedores individuais bloqueiam um ataque (por exemplo, serviços de bloqueio de anexo do Outlook), muitos clientes alternativos populares são ainda vulneráveis, o que também deixa o sistema vulnerável. Os Attachment Execution Services fornecem um framework que permite aos desenvolvedores Microsoft e externos (terceiros) terem acesso aos mesmos serviços enquanto desenvolvem clientes de e-mail e bate-papo.

Com a inclusão do Attachment Execution Services, a Microsoft unificará a abordagem a esse problema. Atualmente, o Outlook emprega um conjunto de APIs que monitoram arquivo anexos e, subseqüentemente, alertam os usuários sobre arquivos potencialmente perigosos, enquanto o Outlook Express inclui arquivo anexos avisando e bloqueando utilizando sua própria técnica. Com o Attachment Execution Services, o Outlook, o Outlook Express e o Windows Messenger poderão contar com um único serviço para proteger os usuários e ajudá-los a tomar decisões de confiabilidade.

No caso do desenvolvedor, isso significa a disponibilidade de APIs adicionais baseadas no COM que podem ser usadas para proteger o usuário.

Segurança de e-mail aprimorada – Implicações para o desenvolvedor Qualquer desenvolvedor que esteja escrevendo ou que planeje escrever um cliente de bate-papo (chat) ou de e-mail ficará interessado nessas mudanças.

Descrição

O Attachment Execute Service baseia-se em um framework de decisão de confiabilidade para executar os arquivos. Com o Attachment Execution Services, os aplicativos não precisarão tomar decisões de confiabilidade quando executarem os anexos. Em vez disso, o Attachment Execution Services cria as decisões de confiabilidade com base na configuração e nos recursos do computador, ao mesmo tempo em que fornece aos usuários mensagens com mais informações para ajudá-los a tomar uma decisão sobre abrir ou não um dado arquivo (como, por exemplo, informações sobre o tratador a ser usado para processar o anexo e informações adicionais sobre a origem do arquivo). Internamente, o Attachment Execution Services atribui uma classificação de risco a cada anexo, com base na extensão, no tipo de conteúdo, nos tratadores registrados e em outros métodos heurísticos. A classificação de risco é então mapeada para uma política que é verificada por meio das zonas de IE familiares (restricted, Internet, intranet, local, e trusted). Esse serviço não oferece nenhuma solução alternativa para subverter o framework de decisão. Embora alguma funcionalidade possa se perder, é uma perda aceitável tendo em vista a mudança.

O ponto de entrada programático do Attachment Execution Services é a interface IAttachmentExecute, que oferece quatro novas chamadas de API:

CheckPolicy() Substitui a interpretação do cliente de AssocIsDangerous() e a configuração/política personalizada. Examina a evidência disponível e confere a política resultante.

PromptUser() Substitui os prompts personalizados por confiança do usuário. Pode ser chamado pelo aplicativo para forçar a interface do

usuário (UI) em um ponto anterior, mesmo antes de o arquivo ser copiado no disco.

Execute Substitui a chamada para ShellExecute(). Assegura que CheckPolicy() e PromptUser() sejam chamados quando necessário. Chama o IAttachmentExecute::PromptUser() com uma ação EXEC.

Save() Assegura que CheckPolicy () seja chamado quando necessário. Salva a evidência no anexo.

Os aplicativos devem chamar IAttachmentExecute::CheckPolicy para determinar a política de execução a ser usada para um determinado anexo. IAttachmentExecute::CheckPolicy examina a evidência, que consiste em um conjunto de propriedades que podem ser definidas por meio do seguinte:

• IAttachmentExecute::SetFileName

• IAttachmentExecute::SetLocalPath

• IAttachmentExecute::SetReferrer

• IAttachmentExecute::SetSource

Chamar IAttachmentExecute::CheckPolicy permite que o aplicativo modifique sua interface de usuário (UI) em função do resultado da chamada.

IAttachmentExecute::CheckPolicy requer que o aplicativo chame primeiro IAttachmentExecute::SetFileName ou IAttachmentExecute::SetLocalPath. No entanto, simplesmente chamando IAttachmentExecute::Save ou IAttachmentExecute:Execute, a política será verificada e, se necessário, o usuário será avisado. A evidência coletada para o anexo também é salva com o anexo, de modo que, quando ele for executado posteriormente, as restrições possam ser reforçadas.

Veja um exemplo de como um cliente de e-mail escrito em C++ pode usar o IAttachmentExecute.

// CClientAttachmentInfo definido pelo cliente // implementa nos anexos toda a funcionalidade de cliente necessária class CClientAttachmentInfo; HRESULT CreateAttachmentServices(IAttachmentExecute **ppae) { // É suposto que CoInitialize() já tenha sido chamado para esse thread HRESULT hr = CoCreateInstance(CLSID_AttachmentServices, NULL, CLSCTX_INPROC_SERVER, IID_IAttachmentExecute, (void**)&pAttachExec); if (SUCCEEDED(hr)) { //Defina o título Client e Guid peloa prompt IU // UUID_ClientID deve ser criado com uuidgen.exe e definido internamente (*ppae)->SetClientGuid(UUID_ClientID); // g_pszTitle é uma substituição opcional para a UI da caixa de diálogo

// (*ppae)->SetClientTitle(g_pszTitle); } return hr; } BOOL IsAttachmentBlocked(CClientAttachmentInfo *pinfo) { // CopyAttachmentToTempFile() copiaria o arquivo do armazenamento de e-mail para um arquivo temp PWSTR pszFileName; HRESULT hr = pinfo->GetFileName(&pszFileName); if (SUCCEEDED(hr)) { IAttachmentExecute *pExecute; hr = CreateAttachmentServices(&pExecute); if (SUCCEEDED(hr)) { hr = pExecute->SetFileName(pszFileName); // não chame SetLocalPath() já que não temos ainda o caminho local // não chame SetSource(), já que não é possível verificar as origens do e-mail // Não chame SetReferrer()m já que não temos uma zona melhor do que a padrão (restrita - restricted) if (SUCCEEDED(hr)) { hr = pExecute->CheckPolicy(); } pExecute->Release(); } LocalFree(pszFileName); } return FAILED(hr); } HRESULT OnDoubleClickAttachment(HWND hwnd, CClientAttachmentInfo *pinfo) { // CopyAttachmentToTempFile() copiaria o arquivo do armazenamento de e-mail para um arquivo temp PWSTR pszTempFile; HRESULT hr = pinfo->CopyToTempFile(&pszTempFile); if (SUCCEEDED(hr)) { IAttachmentExecute *pExecute; hr = CreateAttachmentServices(&pExecute); if (SUCCEEDED(hr)) { hr = pExecute->SetLocalPath(pszTempFile); // não chame SetFileName() já que não temos ainda o caminho local // não chame SetSource(), já que as origens do e-mail não podem ser verificadas // Não chame SetReferrer()m já que não temos uma zona melhor do que a padrão (restrita - restricted) if (SUCCEEDED(hr)) { hr = pExecute->Execute(hwnd, NULL, NULL);

} pExecute->Release(); } LocalFree(pszTempFile); } return hr; } HRESULT OnSaveAttachment(HWND hwnd, CClientAttachmentInfo *pinfo) { // CopyAttachmentToTempFile() copiará o arquivo do armazenamento de e-mails // para um local selecionado pelo usuário PWSTR pszUserFile; HRESULT hr = pinfo->CopyToUserFile(hwnd, &pszUserFile); if (SUCCEEDED(hr)) { IAttachmentExecute *pExecute; hr = CreateAttachmentServices(&pExecute); if (SUCCEEDED(hr)) { hr = pExecute->SetLocalPath(pszTempFile); // não chame SetFileName() já que não temos ainda o caminho local // não chame SetSource(), já que as origens do e-mail não podem ser verificadas // Não chame SetReferrer()m já que não temos uma zona melhor do que a padrão (restrita) if (SUCCEEDED(hr)) { hr = pExecute->Save(); } pExecute->Release(); } LocalFree(pszUserFile); } return hr; }

Para obter informações adicionais sobre as funções IattachmentExecute, consulte: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/ifaces/iattachmentexecute/iattachmentexecute.asp. Ação exigida

O uso de IAttachmentExecute (e do Attachment Execution Services) segue um caminho a partir do recebimento até abrir ou descartar um anexo.

No cenário mais simples, no qual um anexo é salvo no disco rígido de um usuário, isso envolverá substituir chamadas para o código de verificação do tipo de arquivo (ou as chamadas para AssocIsDangerous) bem como a UI personalizada usada para avisar o usuário (com uma única chamada). Esse método IAttachmentExecute::Save chamará os métodos CheckPolicy e PromptUser quando necessário e salvará a evidência coletada no anexo para que este possa ser aberto de forma segura mais tarde, com as restrições de zona reforçadas.

Segurança de navegação aprimorada

Novas tecnologias estarão disponíveis no Internet Explorer para proporcionar uma melhor proteção contra conteúdo malicioso e indesejado na Web. Um dos aprimoramentos inclui locking down the local machine zone (bloqueio da zona local machine) para impedir a execução de scripts mal-intencionados e fortalecer contra downloads na Web perigosos. Outro aprimoramento é a inclusão de um pop-up manager. Além disso, a Microsoft fornecerá melhores controles e interfaces de usuários que ajudarão a impedir a execução de controles ActiveX e spyware nos sistemas dos clientes sem o conhecimento ou a permissão destes.

Bloqueio da zona Local Machine Quando o Internet Explorer abre uma página da Web, ele impõe restrições quanto ao comportamento da página com base na localização dela. Por exemplo, as páginas da Web que estiverem localizadas na Internet provavelmente não conseguirão executar algumas operações, como acessar informações do disco rígido local, porque o IE impede essa funcionalidade com base nas configurações definidas para a zona da Internet.

Por outro lado, as páginas da Web acessadas a partir do computador local são armazenadas na zona Local Machine, local em que desfrutam das menores restrições de segurança. A zona Local Machine é uma zona de segurança do Internet Explorer, mas não aparece nas configurações do Internet Explorer. Até o surgimento do Service Pack 2, a zona Local Machine permitia que o conteúdo da Web fosse executado com menos restrições porque o conteúdo local era considerado seguro. Infelizmente, os atacantes tentam tirar proveito da zona Local Machine para aumentar os privilégios deles e violar um computador.

No Windows XP Service Pack 2, todo o conteúdo e os arquivos locais processados pelo Internet Explorer recebem uma segurança adicional na zona Local Machine.

Esse recurso limita consideravelmente o HTML que está na zona Local Machine e o que está hospedada no Internet Explorer, o que ajuda a diminuir os ataques em que a zona Local Machine é usada como vetor de ataque para carregar código HTML malicioso.

Quando o Internet Explorer é executado na zona Local Machine, as configurações de segurança padrão das zonas de segurança, conhecidas como URLActions, são substituídas por configurações ainda mais restritivas do que as da zona da Internet. Mais especificamente, são estas as configurações:

• URLACTION_ACTIVEX_ RUN muda para Disallow.

• URLACTION_ACTIVEX_OVERRIDE_OBJECT_SAFETY muda para Disallow.

• URLACTION_SCRIPT_ RUN muda para Prompt.

• URLACTION_CROSS_DOMAIN_ DATA muda para Prompt.

• URLACTION_BINARY_BEHAVIORS_BLOCK muda para Disallow.

• URLACTION_JAVA_PERMISSIONS muda para Disallow.

Essa alteração ajuda a impedir que o código HTML malicioso que entrou no computador do usuário aumente seus privilégios, pois, com um privilégio elevado, ele poderia executar qualquer código por meio de um controle ActiveX ou da leitura de informações com script.

Devido a essa mudança, o script ActiveX nas páginas HTML locais que são exibidas no Internet Explorer não será executado. O script dessas páginas solicita permissão do usuário para ser executado.

As configurações a seguir descritas na Tabela 6 são adicionadas ou alteradas durante a navegação no Windows XP Service Pack 2.

Nome da Localização Valor Valores possíveis

configuração padrão

IExplore.exe HKEY_LOCAL_MACHINE \Software\Microsoft \Internet Explorer\main \FeatureControl\FEATURE_LocalMachine_Lockdown HKEY_CURRENT_USER \Software\Microsoft \Internet Explorer\main \FeatureControl\FEATURE_LocalMachine_Lockdown

1 1 - Aplica configurações restritivas ao Iexplore.exe e ao Explorer.exe Qualquer outro valor desativa a mitigação para o Iexplore.exe e o Explorer.exe Se a configuração não tiver sido definida para o Iexplore.exe, isso não será observado. Se ela estiver presente em HKEY_LOCAL_MACHINE e em HKEY_CURRENT_USER, a configuração mais segura será usada.

ApplicationName.exe

HKEY_LOCAL_MACHINE \Software\Microsoft \Internet Explorer\main \FeatureControl\FEATURE_LocalMachine_Lockdown HKEY_CURRENT_USER \Software\Microsoft \Internet Explorer\main \FeatureControl\FEATURE_LocalMachine_Lockdown

None 1 - Aplica configurações restritivas a ApplicationName.exe. Qualquer outro valor desativa a mitigação para ApplicationName.exe Se a configuração não tiver sido definida para ApplicationName.exe, isso não será observado. Se a configuração estiver presente em HKEY_LOCAL_MACHINE e em HKEY_CURRENT_USER, a configuração mais segura será usada.

Tabela 6: Inclusões e/ou alterações na navegação no Windows XP Service Pack 2 Aplicativos não compatíveis com essas regras e configurações mais rigorosas podem prejudicar os usuários.

Bloqueio da zona Local Machine – implicações para o desenvolvedor Todos os desenvolvedores de aplicativos devem analisar esse recurso.

Descrição

Os aplicativos que hospedam arquivos HTML locais no Internet Explorer tendem a ser afetados pelo bloqueio da zona Local Machine. Desenvolvedores de aplicativos autônomos devem considerar a adoção de alterações nos aplicativos que criarem e que hospedarem o Internet Explorer.

Ação exigida

Por padrão, o Local Machine Lockdown não está ativado para processos que não sejam do Internet Explorer, e os desenvolvedores precisarão registrar seus aplicativos para poderem usufruir das alterações as quais asseguram que código malicioso não conseguirá ser executado através dos aplicativos deles. É recomendado que os aplicativos que não usam essa mitigação devem ser avaliados de modo independente para vetores de ataques à zona Local Machine.

Os desenvolvedores de aplicativos que hospedam o Internet Explorer devem usar esse recurso e adicionar o nome do processo deles ao registro, como mostrado acima.

No futuro, a Microsoft provavelmente implementará esse recurso usando uma diretiva opcional externa em vez de uma diretiva opcional interna.

Os aplicativos que hospedam o Internet Explorer devem ser testados para garantir que funcionem corretamente quando o Local Machine Zone Lockdown estiver ativado para seus processos.

Se o conteúdo HTML local for executado no Internet Explorer e apresentar problemas devido a essa mitigação, você poderá salvá-lo como um arquivo HTA (aplicativo HTML) e tentar executá-lo novamente na zona Local Machine. Os HTAs são hospedados em um processo diferente e, portanto, não são afetados pela mitigação. Mas, como são executados com privilégios totais, eles podem ser perigosos. É preciso ter cuidado ao permitir que um código não confiável seja executado dessa maneira.

Nos cenários em que os documentos HTML são baixados da Web, é possível adicionar um comentário de "marca da Web" existente no arquivo HTML às páginas deles na Web. Por exemplo, você poderia adicionar <!-- saved from url=(0023)http://www.contoso.com/ --> a uma página da Web, em que o valor (0023) corresponde ao tamanho da string da URL que o segue e Contoso é o nome do site. Quando o Internet Explorer carrega o arquivo, ele procura o comentário "saved from URL", lê o URL e usa as configurações da zona no computador para determinar qual diretiva de segurança deve aplicar à página da Web. Esse recurso do Internet Explorer permite que os arquivos HTML sejam forçados para uma zona que não a zona local a fim de serem atribuídos à zona da Internet e, com esses privilégios de segurança reduzidos, poderem executar o script ou o código ActiveX.

Uma alternativa seria criar um aplicativo separado que hospedasse o WebOC (Internet Explorer Web Object Control) do conteúdo HTML. Nesse caso, a HTML não estaria mais limitada pelas mesmas regras que se aplicam ao conteúdo executado no Internet Explorer. E, quando o conteúdo HTML fosse executado nesse outro processo, ele poderia usufruir de direitos completos, conforme definido pelo desenvolvedor ou pela diretiva de zona desse processo.

Notas

• Se os sites forem executados nas zonas da Internet ou da intranet local, você não será afetado por essas alterações.

• Convém que os administradores de rede usem scripts locais que serão afetados por essas restrições. Os administradores devem analisar as soluções disponíveis para ativar seus scripts locais sem violar a segurança da área de trabalho de seus usuários.

Pop-up Manager do Internet Explorer Os pop-ups vêm sendo usados de muitas maneiras inadequadas. Quando eles são bloqueados, a Web torna-se bem mais segura para usuários finais e o cliente passa a ter mais controle sobre a experiência de navegação.

O Pop-up Manager impede que janelas pop-up indesejadas apareçam. No entanto, as janelas de pop-up que são iniciadas quando o usuário final clica em um link não são bloqueadas.

Os usuários finais e administradores de TI podem permitir que domínios específicos iniciem janelas pop-up de modo programático. Os desenvolvedores poderão usar ou ampliar a funcionalidade dos pop-ups no Internet Explorer para aplicativos que hospedem o Internet Explorer.

Para os usuários finais, esse procedimento fará com que seja mais seguro e mais agradável navegar na Web porque as janelas pop-up não aparecerão automaticamente.

Recursos do Pop-up Manager

Por padrão, o Pop-up Manager está desativado. Quando essa funcionalidade é ativada, as janelas pop-up automáticas e de segundo plano são bloqueadas na zona da Internet, mas as janelas que forem abertas quando um usuário final clicar em um link continuarão sendo abertas do modo convencional, embora também exista uma configuração específica para isso. Note que as janelas pop-up dos sites das zonas de sites confiáveis e da intranet local (Trusted Sites e Local Intranet zones) nunca são bloqueadas porque são consideradas seguras. Esse comportamento pode ser configurado na guia Segurança em Opções da Internet.

É possível ativar o Pop-up Manager usando três métodos diferentes.

1. Prompt na primeira ocorrência. Um prompt que aparece antes da primeira janela pop-up solicita que o cliente ative o Pop-up Manager.

2. Menu Ferramentas. No Internet Explorer, você pode clicar em Ferramentas, apontar para Pop-up Manager e clicar em Block Pop-up Windows.

3. Opções da Internet. No Internet Explorer, clique em Ferramentas e em Opções da Internet, clique na guia Privacidade e, em seguida, clique em Block pop-up windows. Depois, clique em Opções para definir as configurações do Pop-up Manager, como mostrado na Figura 14.

Figura 14: Caixa de diálogo Pop-up Window Management

Se um site iniciar uma janela pop-up que esteja bloqueada pelo Internet Explorer, aparecerá um aviso na barra de status e tocará um som. Se o usuário clicar na barra de status, será exibido um menu com as seguintes opções:

• Show Blocked Pop-up Window. Carrega novamente a janela pop-up.

• Allow Pop-up Windows from This Site. Adiciona o site atual à lista de permitidos (Allow list). Os sites podem ser adicionados a essa lista em um aplicativo de configuração por um administrador.

• Block Pop-up Windows. Ativa/desativa o Pop-up Manager.

• Pop-up Window Options. Abre a janela Pop-up Window Management.

Note que existem novas restrições no Internet Explorer quanto ao tamanho e à posição das janelas pop-up, independentemente da configuração do Pop-up Manager: as janelas pop-up não podem ser abertas em um tamanho maior do que a área de trabalho visível nem fora dessa área.

O Internet Explorer também permite uma definição avançada das configurações do Pop-up Manager.

As configurações podem ser usadas da seguinte maneira:

Web Site Allow List. Você pode adicionar sites à lista de permitidos (Allow list). Qualquer site que esteja nessa lista pode abrir janelas pop-up.

Block All Pop-up Windows. O Pop-up Manager permite que os sites abram uma janela pop-up quando o usuário clicar em um link. Essa configuração muda o comportamento, bloqueando as janelas que são abertas a partir de um link. Se essa configuração estiver ativa, você pode permitir que janelas pop-up sejam abertas pressionando ALT ao mesmo tempo em que clica no link.

Tecla de substituição (Override Key). Quando a opção Block All Pop-up Windows estiver ativa, você poderá permitir que janelas pop-up sejam abertas pressionando ALT ao mesmo tempo em que clica no link.

Configurar som. Você pode especificar se o Pop-up Manager tocará ou não um som quando uma janela pop-up estiver bloqueada. Para isso, use as configurações Avançadas em Opções da Internet. Você também pode alterar o som que é tocado. Para isso, clique em Iniciar, clique em Painel de Controle e, em seguida, clique duas vezes no ícone Dispositivos de Sons e Áudio.

Zonas. Os clientes podem estender o escopo do Pop-up Manager para incluir as zonas da intranet local ou de sites confiáveis na guia Segurança de Opções da Internet.

Os clientes continuarão a ver pop-ups inicializados nos casos descritos a seguir:

• O pop-up é aberto por meio de um link em que o usuário clicou.

• O pop-up é aberto pelo software que está sendo executado no computador.

• O pop-up é aberto por controles ActiveX que são instanciados de um site.

• O pop-up é aberto a partir das zonas de sites confiáveis ou da intranet local.

Pop-up Manager do Internet Explorer − implicações para o desenvolvedor

É importante que os desenvolvedores estejam familiarizados com o modo como o Pop-up Manager funciona para assegurar que os aplicativos existentes continuem a funcionar e permitir que novos aplicativos usem e estendam essa funcionalidade.

Descrição

No que diz respeito aos desenvolvedores Web, o Pop-up Manager afeta o comportamento das janelas abertas por sites da Web, como as que são abertas usando os métodos window.open(), window.showModelessDialog(), window.showModalDialog(), window.navigateAndFind() e window.showHelp(). Se normalmente uma função retornar um objeto windows, ela retornará um valor nulo quando uma janela estiver bloqueada.

Além disso, para desenvolvedores de aplicativos, existe uma nova interface COM: INewWindowManager. Essa interface permite aos aplicativos que usam o mecanismo de processamento no Internet Explorer para exibir HTML, utilizarem ou estenderem a funcionalidade do Pop-up Manager, bem como usarem seu próprio gerenciador de pop-ups ou desativarem o gerenciamento de pop-ups.

Ação exigida

Embora seja possível adicionar um site da Web específico à lista de permitidos (Allow List), se o software abrir janelas automaticamente, elas provavelmente serão bloqueadas. Como resultado, será gerada uma exceção Access Denied JavaScript. O código pode verificar esse erro de uma das seguintes maneiras. Primeiro, se a versão do navegador permitir (IE 5.0 e superior), o script poderá usar uma construção try/catch e verificar o erro. Um segundo método seria permitir que a função abra a janela para configurar o manipulador de erro JavaScript. Nesse caso, o manipulador de erro será executado quando a exceção JavaScript ocorrer. A página a seguir demonstra esses dois métodos.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD> <title>Popup Tester</title> </HEAD> <body> <form id="Form1" method="post" runat="server"> <P><INPUT type="button" value="Open" onclick="openWin()"></P> <P><INPUT type="button" value="ShowHelp" onclick="showPopup()"></P> </form> </body> <script language=javascript > function openWin() { try { window.open("http://www.msn.com","MSN") } catch (e) { window.alert("Popup window blocked " + e.number); } } function handlePopupErrors() {

window.alert("Error occurred"); return true; } function showPopup() { window.onerror = handlePopupErrors; window.showHelp("http://www.msn.com",""); } </script> </HTML>

Você deve verificar quanto ao valor NULL retornado para quaisquer janelas que estejam abertas. Isso indicará se a janela pop-up foi aberta corretamente e permitirá que você lide com qualquer um dos casos.

Embora seja possível interceptar erros resultantes de pop-ups bloqueados dessa forma, é melhor procurar maneiras alternativas de realizar a mesma tarefa (por exemplo, permitindo que o usuário clique em um link ou em um elemento gráfico).

Notas

• Também existem várias restrições novas impostas a janelas no Internet Explorer que, por padrão, estão ativadas (HKEY_LOCAL_MACHINE\Software\Microsoft \Internet Explorer\Window Restrictions\). São elas:

o Quando uma janela é criada, a definição da especificação fullscreen=yes é alterada para indicar "mostrar a janela como maximizada", o que manterá a barra de título, a barra de endereço e a barra de status visíveis.

o Os scripts não podem redimensionar nem reposicionar janelas de modo que oculte a barra de título, a barra de endereço ou a barra de status.

o A barra de status não pode ser desativada por nenhum motivo.

o As janelas pop-up iniciadas por script (abertas com o uso de window.createPopup()) apresentam limitações verticais, horizontais e da ordem de posicionamento sobre outras janelas.

Resumo Obrigada por participar deste curso. Você concluiu os seguintes objetivos:

• Resumir as justificativas para uma maior segurança no Windows XP SP2.

• Identificar as quatro áreas de desenvolvimento afetadas por este service pack.

• Rever a situação atual.

• Identificar as áreas comuns em que os aplicativos serão quebrados após a implantação do XP SP2.

• Identificar as possíveis correções a curto prazo e as soluções a longo prazo.

• Explicar como os exemplos de atualizações de aplicativos permitem que o desenvolvedor tire proveito das alterações feitas pelo XP SP2.

• Descrever as próximas etapas que devem ser efetuadas para corrigir os problemas que podem surgir com a instalação do XP SP2.

Lembre-se de que a implantação do Windows XP Service Pack 2 afetará consideravelmente o desenvolvedor. No entanto, o objetivo do Service Pack é proporcionar ao cliente um ambiente de computação mais seguro. Na condição de desenvolvedor, você pode tornar isso uma realidade através de um planejamento cuidadoso e da criação de aplicativos para a plataforma XP.