MS09-012: Descrição da atualização de segurança do Windows Service Isolation: Abril de 2009

• Usuários domésticos:
  http://www.microsoft.com/brasil/athome/security/update/bulletins/200904.mspx (http://www.microsoft.com/brasil/protect/computer/updates/bulletins/200904.mspx)
  Ignorar os detalhes: Baixe agora as atualizações para o computador particular ou laptop pelo site Microsoft Update:
  http://update.microsoft.com/microsoftupdate/ (http://update.microsoft.com/microsoftupdate/)
• Profissionais de TI:
  http://www.microsoft.com/brasil/technet/security/bulletin/MS09-012.mspx (http://www.microsoft.com/brasil/technet/security/bulletin/MS09-012.mspx)

Voltar para o início

Como obter ajuda e suporte para esta atualização de segurança

Voltar para o início

Problemas conhecidos desta atualização de segurança

• Sintomas
  Depois que você aplica a atualização em um servidor que usa mais de quatro núcleos de CPU e que está executando o Microsoft ISA Server Standard Edition, o Serviço de controle do Microsoft ISA Server não é iniciado. Além disso, a Identificação do evento 14109 é registrada no log do aplicativo.
  
  Motivo
  Esse problema poderá ocorrer se um hotfix lançado depois de 7 de fevereiro de 2007 for instalado antes da atualização de segurança. Esse problema ocorre em função de uma alteração na forma com que o Windows reporta o número de CPUs disponíveis. Essa alteração foi apresentada pela primeira vez no hotfix 932730. Ela faz com que o Windows Server 2003 reporte as informações exatamente da mesma forma que o Windows Vista e o Windows Server 2008. Quando o Windows reporta mais de quatro núcleos de CPU, o Serviço de controle do ISA Server interpreta que há mais de quatro CPUs. Isso dispara um alerta e desliga o Serviço de controle do Microsoft ISA Server e todos os serviços dependentes.
  
  Observação O hotfix 932730 não foi incluído em nenhum service pack do Windows Server 2003. Para obter mais informações sobre o hotfix 932730, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft :
  932370  (http://support.microsoft.com/kb/932370/ ) O número dos processadores físicos habilitados para hyperthreading ou o número de processadores físicos com vários núcleos é reportado incorretamente no Windows Server 2003
  Para obter mais informações sobre como contornar esse problema, visite a seguinte página da Web da Microsoft :
  http://blogs.technet.com/isablog/archive/2009/04/18/ms09-012-and-isa-server-standard-edition-14109-failures.aspx (http://blogs.technet.com/isablog/archive/2009/04/18/ms09-012-and-isa-server-standard-edition-14109-failures.aspx)
  Para resolver esse problema do ISA Server 2004, instale o rollup de hotfix 970454. Para obter mais informações sobre esse problema, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft:
  970454  (http://support.microsoft.com/kb/970454/ ) Descrição do pacote de hotfix do ISA Server 2004: 2 de junho de 2009
  Para resolver esse problema do ISA Server 2006, instale o rollup de hotfix 970441. Para obter mais informações sobre esse problema, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft:
  970441  (http://support.microsoft.com/kb/970441/ ) CORREÇÃO: Não é possível iniciar o serviço de controle do ISA Server depois que a atualização MS09-012 é instalada em computadores que executam o Windows Server 2003 e que possuem mais de 4 núcleos de CPU
  
  Observação Nenhum patch foi emitido para o ISA Server 2000, pois o ISA Server 2000 não está mais no suporte base e esse problema não representa uma vulnerabilidade de segurança.
• Após a aplicação desta atualização e a execução de uma atualização local de um sistema operacional lançado anteriormente para um novo sistema, as alterações feitas pelo usuário podem não ser preservadas nas seguintes subchaves do Registro:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\DefaultSecuredHost

  
  
  

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\CompatibleHostProviders

  
  
  

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders
  Esse problema pode ocorrer nos seguintes cenários de atualização:
  • Windows XP para Windows Vista
  • Windows Server 2003 para Windows Server 2008
  • Windows 2000 Server para Windows Server 2003
  Esse problema não ocorre nos seguintes cenários de atualização:
  • Windows Vista para Windows 7
  • Windows Server 2008 para service packs mais recentes ou futuros sistemas operacionais com base em servidor.
  Para evitar esse problema, faça backup dessas subchaves antes de executar a atualização local. Aplique os backups da subchave novamente depois que a atualização estiver concluída e o sistema for corrigido com as atualizações de segurança.

Voltar para o início

Perguntas frequentes para fornecedores de software independentes (ISV) (COM)

1. Seu produto precisa iniciar um processo de servidor COM que não seja do serviço do NT?
2. Por padrão, o servidor COM que o seu produto cria instâncias é executado no contexto do Serviço de Rede ou da Conta de Serviço Local?

1. Baixe e instale o Process Explorer no seguinte site da Microsoft:
   http://technet.microsoft.com/pt-br/sysinternals/bb896653.aspx (http://technet.microsoft.com/pt-br/sysinternals/bb896653.aspx)
2. Execute o Process Explorer como administrador local.
3. Clique em Exibir, aponte para Exibição do Painel Inferior e clique em Identificadores.
4. Clique no processo de servidor desejado e procure Tipo = Token no painel inferior.
5. Execute todos os conjuntos de teste para seu produto.
6. Busque no painel inferior todos os tokens existentes para saber se um token do sistema foi capturado.

1. Baixe e instale as Ferramentas de Depuração do Windows no seguinte site da Microsoft:
   http://www.microsoft.com/whdc/devtools/debugging/default.mspx (http://www.microsoft.com/whdc/devtools/debugging/default.mspx)
2. Execute o WinDBG.exe como administrador local.
3. Clique em Arquivo e em Depuração de Kernel para iniciar o depurador de kernel local.
4. Clique em Arquivo e em Anexar a um Processo.
5. Clique no processo de servidor desejado e em OK para anexar ao processo de servidor.
6. Configure o caminho de símbolo do depurador conforme instruções a seguir. Substitua o caminho de armazenamento do downstream por Armazenamento Downstream. Por exemplo, C:\Symbols.
   
   SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols
7. Elimine as informações de token do processo.
   Obtenha o endereço do token por meio da saída do processo e use o comando dt nt!_TOKEN para exibir uma lista dos campos individuais da estrutura do TOKEN.
8. Observe o campo ImpersonationLevel do token.

• Instale o pacote MSRC.
• Faça a seguinte alteração na configuração do servidor COM:
  HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{APPIDGUID} REG_DWORD AppIDFlags 0x2 /* Exemplo de uso do valor do Registro AppIDFlags HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{60EE1F45-C0DD-4A1F-AA44-D97424600A16} REG_DWORD AppIDFlags 0x2 */
  Observação as credenciais do administrador local são necessárias para fazer alterações.
  
  Se um servidor COM NS/LS que contém tokens privilegiados não for do serviço do NT ou não for um servidor COM "Executar Como", ele deverá ser convertido para uma dessas configurações para evitar a vulnerabilidade.

• O instalador deverá determinar se a seguinte chave do Registro existe:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\KB956572
  Se essa entrada do Registro existir, a atualização de segurança 956572 estará presente no sistema.

Voltar para o início

Perguntas frequentes para administradores de sistema (COM)

1. Seu produto precisa iniciar um processo de servidor COM que não seja do serviço do NT?
2. Por padrão, o servidor COM que o seu produto inicia é executado no contexto do Serviço de Rede ou da Conta de Serviço Local?

Voltar para o início

Perguntas frequentes para ISVs (Services.exe)

1. Seu produto instala serviços que são iniciados pelo uso da estrutura SCM?
2. Por padrão, os serviços que o seu produto instala são executados no contexto do Serviço de Rede ou da Conta de Serviço Local?
3. Se o seu serviço é executado no Windows Vista ou no Windows Server 2008, execute o seguinte comando a partir de um prompt de comando elevado:
   SC.EXE QSIDTYPE <ServiceName>
   O valor SERVICE_SID_TYPE está definido como NENHUM?
   
   Saída:

   [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Service Name> SERVICE_SID_TYPE: NENHUM 

   Se a resposta para essas perguntas for sim, seu serviço poderá estar vulnerável. Para continuar a investigação sobre as vulnerabilidades do serviço, siga as etapas relacionadas ao Process Explorer na Resposta 1 da seção "Perguntas frequentes para fornecedores de software independentes (ISV) (COM)".

• Instale o pacote MSRC.
• Execute o seguinte comando a partir de um prompt de comando elevado:
  SC.exe SIDTYPE <ServiceName> UNRESTRICTED
• Reinicie o serviço por meio do Gerenciador de controle de serviços.
• Para confirmar se o serviço obteve um SID de serviço, execute o seguinte comando:
  SC.exe QSIDTYPE <Service Name>
  Saída:

  [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Service Name> SERVICE_SID_TYPE: UNRESTRICTED  

• Se SERVICE_SID_TYPE = UNRESTRICTED for exibido, significa que o serviço obteve um SID.
• Execute todos os casos de teste para verificar se alguma das funcionalidades fornecidas pelo serviço está inválida.
• A seguinte sequência de comandos ajudará na remoção do SID de serviço:
  SC.exe SIDTYPE <ServiceName> NENHUM
  SC.exe STOP <ServiceName>
  SC.exe START <ServiceName>

1. Altere a seguinte chave do Registro:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<ServiceName>\ServiceSidType = 1
2. Após essa atualização, o instalador deverá reiniciar o sistema.

• O instalador deverá determinar se a seguinte chave do Registro existe:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\KB956572
  Se essa entrada do Registro existir, a atualização de segurança 956572 estará presente no sistema.

Voltar para o início

Perguntas frequentes para administradores de sistema (Services.exe)

1. Seu produto instala serviços que são iniciados pelo uso da estrutura SCM?
2. Por padrão, os serviços que o seu produto instala são executados no contexto do Serviço de Rede ou da Conta de Serviço Local?
   
   Observação Se o serviço for executado no Windows Vista ou no Windows Server 2008, execute um dos seguintes comandos a partir de um prompt de comando elevado para determinar o contexto:
   SC.exe QSIDTYPE <Service Name>
   Saída:

   [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Service Name> SERVICE_SID_TYPE: UNRESTRICTED  

   Se a resposta para essas perguntas for sim, esses serviços poderão estar vulneráveis. Para ajudar a proteger esses serviços, entre em contato com o ISV que possui o serviço. Se o serviço tiver sido desenvolvido internamente, siga as etapas na Resposta 1 da seção "Perguntas frequentes para fornecedores de software independentes (ISV) (COM)".

Voltar para o início

Perguntas frequentes para fornecedores de software independentes (ISV) (WMI)

1. Abra os arquivos ".mof" dos provedores WMI e verifique se algum deles possui um dos seguintes modelos de hospedagem:
   • NetworkServiceHost
   • NetworkServiceHostToSelfHost
   • LocalServiceHost
   • NULO (somente para Windows Vista ou Windows Server 2008)
2. Como parte do pacote de captura de token, somente os provedores WMI enviados para a caixa de entrada são seguros por padrão. Se você possui um provedor de caixa de entrada, ele deverá estar seguro após a instalação do pacote de captura de token. Para confirmar isso, verifique os valores do Registro na subchave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders. Se o provedor estiver seguro, será exibida um entrada semelhante ao seguinte:

   <NameSpace>:_Win32Provider.Name ="<Nome do Provedor>" 	REG_SZ 	0.

3. Se o seu provedor estiver listado aqui, então o provedor particular será iniciado no modo seguro.
4. Se o nome do provedor não estiver listado na chave do Registro SecureHostProviders e o modelo de hospedagem for um dos modelos listados na etapa 1, então esse provedor será lançado em um Wmiprvse.exe não seguro e tornará o computador vulnerável ao ataque de captura de token.

1. Faça logon como administrador em um computador que tenha seu produto instalado.
2. Baixe e instale o Process Explorer no seguinte site da Microsoft:
   http://technet.microsoft.com/pt-br/sysinternals/bb896653.aspx (http://technet.microsoft.com/pt-br/sysinternals/bb896653.aspx)
3. Execute o Process Explorer como administrador local.
4. Clique em Exibir, aponte para Exibição do Painel Inferior e clique em Identificadores.
5. Use o Gerenciador de tarefas para identificar e fechar todos os processos Wmiprvse.exe que estiverem sendo executados no contexto do Serviço de Rede ou do Serviço Local.
6. Use um provedor WMI específico para executar um caso de teste no aplicativo que usa a consulta WMI. Isso criará um novo processo WMIPrvSE.exe para atender à nova consulta WMI executada anteriormente.
7. Na barra de ferramentas do Process Explorer, verifique se a opção Exibir DLLs está selecionada.
8. Observe o painel inferior para verificar se a sua DLL foi carregada no WMIPrvSE.exe criado anteriormente.
9. Clique duas vezes em WMIPrvSE.exe para abrir a caixa de diálogo Propriedades.
10. Clique na guia Segurança e verifique se os itens a seguir estão corretos:
    • O SID de logon tem o formato (S-1-5-5-****).
    • O SID de logon também está marcado como proprietário.
    • O SID do WMI da conta de serviço {Local Service|Network Service} será marcado como proprietário.
      • SID do WMI para o Serviço Local:
        S-1-5-86-1544737700-199408000-2549878335-3519669259-381336952
      • SID do WMI para o Serviço de Rede:
        S-1-5-86-615999462-62705297-2911207457-59056572-3668589837
11. Clique em Permissão e verifique se nem o Serviço de Rede nem o Serviço Local aparecem na lista. Isso servirá para confirmar se o provedor está sendo iniciado no modo seguro.

• HKLM\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders
  
  Todos os provedores listados nessa chave serão sempre executados no modo seguro.
• HKLM \SOFTWARE\Microsoft\WBEM\CIMOM\CompatibleHostProviders
  
  Se houver um provedor listado nessa chave, ele será executado no modo não seguro. Essa chave existe para que um ISV possa adicionar uma exceção a um provedor particular que tenha problemas de compatibilidade ao ser executado no modo seguro. Por padrão ele apresentará 0 (zero) entradas.
• HKLM \SOFTWARE\Microsoft\WBEM\CIMOM\DefaultSecuredHost
  
  Se essa chave do Registro global estiver definida como 1, ele iniciará todos os provedores WMI do computador no modo seguro independentemente de estarem listados ou não em alguma chave do Registro acima. A Microsoft não definiu a chave como 1 por padrão porque nem todos os aplicativos de outros fabricantes foram testados com essa chave do Registro.

<NameSpace>:_Win32Provider.Name =?<Nome do Provedor>? 	REG_SZ 	0.

Voltar para o início

Perguntas frequentes para o administrador do sistema (WMI)

1. Faça logon como administrador em um computador que tenha seu produto instalado.
2. Baixe e instale o Process Explorer no seguinte site da Microsoft:
   http://technet.microsoft.com/pt-br/sysinternals/bb896653.aspx (http://technet.microsoft.com/pt-br/sysinternals/bb896653.aspx)
3. Execute o Process Explorer como administrador local.
4. Clique em Exibir, aponte para Exibição do Painel Inferior e clique em Identificadores.
5. Use o Gerenciador de tarefas para identificar e fechar todos os processos Wmiprvse.exe que estiverem sendo executados no contexto do Serviço de Rede ou do Serviço Local.
6. Use um provedor WMI específico para executar um caso de teste no aplicativo que usa a consulta WMI. Isso criará um novo processo WMIPrvSE.exe para atender à nova consulta WMI executada anteriormente.
7. Na barra de ferramentas do Process Explorer, verifique se a opção Exibir DLLs está selecionada.
8. Observe o painel inferior para verificar se a sua DLL foi carregada no WMIPrvSE.exe criado anteriormente.
9. Clique duas vezes em WMIPrvSE.exe para abrir a caixa de diálogo Propriedades.
10. Clique na guia Segurança e verifique se os itens a seguir estão corretos:
    1. "Serviço de Rede" ou "Serviço Local" tem permissão total sobre o processo Wmiprvse.exe.
    2. Verifique se o SID de logon (no formato S-1-5-5-**** ) não está marcado como proprietário.
    3. Verifique se o SID do WMI da conta de serviço {Local Service|Network Service} não foi gerado. Ou seja, verifique se ele não está visível em "Grupo".
       • SID do WMI para o Serviço Local: S-1-5-86-1544737700-199408000-2549878335-3519669259-381336952
       • SID do WMI para o Serviço de Rede: S-1-5-86-615999462-62705297-2911207457-59056572-3668589837

1. Abra o Editor do Registro.
2. Acesse a seguinte subchave do Registro:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders
3. Adicione um valor do Registro no provedor WMI a ser protegido. Use o seguinte formato:

   <NameSpace>:_Win32Provider.Name =?<Nome do Provedor>? 	REG_SZ 	0

4. Reinicie o serviço WMI executando os seguintes comandos.
   • Sc stop winmgmt
   • Sc start winmgmt

Voltar para o início

• Os arquivos que se aplicam a uma etapa específica (RTM, SPn) estão indicados na coluna "Requisito de SP".
• Além dos arquivos listados nessas tabelas, esta atualização de software também instala um arquivo associado do catálogo de segurança (KBnúmero.cat) que está assinado com uma assinatura digital da Microsoft.

• Os arquivos que se aplicam a uma etapa ou produto específico (RTM, SPn) podem ser identificados examinando os números da versão do arquivo na tabela a seguir.
  Recolher esta tabelaExpandir esta tabela

  Versão	Produto	Etapa	Ramificação do serviço
  6.0.6000. 20xxx	Windows Vista	RTM	LDR
  6.0.6001. 22xxx	Windows Vista SP1 e Windows Server 2008 SP1	SP1	LDR

• O Service Pack 1 está integrado na versão de lançamento original do Windows Server 2008. Por isso, os arquivos da etapa RTM se aplicam somente ao Windows Vista. Os arquivos da etapa RTM tem um número de versão 6.0.0000.xxxxxx.
• Os arquivos MANIFEST (.manifest) e os arquivos MUM (.mum) instalados para cada ambiente são listados separadamente. Os arquivos MUM e MANIFEST, bem como os arquivos associados do catálogo de segurança (.cat), são importantes para manter o estado do componente atualizado. Os arquivos do catálogo de segurança (atributos não listados) são assinados com uma assinatura digital da Microsoft.