Microsoft Security Bulletin MS11-100 - Crítica

A atenuação refere-se a uma configuração, configuração comum ou prática recomendada geral, existindo num estado padrão, que possa reduzir a gravidade de exploração de uma vulnerabilidade. Os fatores de atenuação a seguir podem ser úteis em sua situação:

• Por padrão, o IIS não está habilitado em nenhum sistema operacional Windows.
• Os sites que rejeitam os tipos de conteúdo HTTP application/x-www-form-urlencoded ou multipart/form-data não estão vulneráveis
• Por padrão, o ASP.NET não está instalado quando o .Net Framework estiver instalado. Somente os clientes que instalam e capacitam manualmente o ASP.NET estão provavelmente vulneráveis a este problema.

A solução alternativa refere-se a uma configuração ou alteração de configuração que não corrige a vulnerabilidade subjacente mas que ajudaria a bloquear vetores de ataque conhecidos antes de aplicar a atualização. A Microsoft testou as soluções alternativas e estados a seguir como parte do cenário que implica se uma solução alternativa reduziria funcionalidade:

• Solução alternativa com base na configuração

  A solução alternativa a seguir configura o limite do tamanho máximo de solicitação que o ASP.NET aceitará de um cliente. Diminuir o tamanho máximo de solicitação diminuirá a suscetibilidade do servidor ASP.NET a um ataque de negação de serviço.

  Observação: Faça o backup da configuração antes de fazer qualquer alteração.

  O valor desta configuração pode ser aplicado globalmente a todos os sites ASP.NET de um servidor adicionando a entrada à raiz web.config ou applicationhost.config. Ou pode-se restringir a configuração a um determinado site ou aplicativo adicionando-a a um arquivo web.config do site ou aplicativo específico. Para obter mais informações sobre a configuração ASP.NET, consulte o artigo da MSDN Visão geral da configuração ASP.NET.

  1. Se seu aplicativo usa ViewState, adicione a seguinte configuração no arquivo de configuração apropriado do ASP.NET para limitar o tamanho máximo de solicitação que ASP.NET aceitará de um cliente a 200 KB.<configuration>  <system.web>  <httpRuntime maxRequestLength="200”/>  </system.web></configuration>
  2. Se seu aplicativo não usa ViewState, adicione a seguinte configuração no arquivo de configuração apropriado do ASP.NET para limitar o tamanho máximo de solicitação que ASP.NET aceitará de um cliente a 20 KB.<configuration>  <system.web>  <httpRuntime maxRequestLength="20”/>  </system.web></configuration>

  Para obter mais informações sobre a opção de configuração maxRequestLength, consulte a documentação da MSDN no Elemento HTTP Runtime.

  Observação: Aumentar a cadeia de caracteres HTTP padrão e solicitar limites de tamanho de cabeçalho aumentarão a suscetibilidade do servidor ao problema de negação de serviço descrito neste comunicado. Para obter mais informações sobre como configurar estes limites, consulte configurações de registro de Http.sys para IIS.

  Impacto da solução alternativa: As solicitações do cliente que excederem o maxRequestLength configurado resultarão em uma ConfigurationErrorsException em todo o lado do servidor, e um status de erro de http retornará ao cliente. Os limites configurados previamente serão usados como linha de base e poderão ser ajustados para evitar falhas do aplicativo. Configurar o valor de maxRequestLength com um valor menor também reduz a susceptibilidade do servidor a esta negação específica de serviço. Os aplicativos que aceitam uploads de arquivo de cliente e os que geram um viewstate grande são exemplos de aplicativos que podem ser impactados por esta solução alternativa.

  Depois que você aplica esta solução alternativa, a seguinte falha de solicitação de cliente pode aparecer em log de eventos do aplicativo.

  Código o evento: 3004 Mensagem do evento: O tamanho do lançamento excedeu os limites permitidos. Informação da exceção:     Tipo de exceção: HttpException     Mensagem da exceção: Tamanho máximo de solicitação excedido.   em System.Web.HttpRequest.GetEntireRawContent()   em System.Web.HttpRequest.FillInFormCollection()   em System.Web.HttpRequest.get_Form()   em System.Web.HttpRequest.get_HasForm()   em System.Web.UI.Page.GetCollectionBasedOnMethod(Boolean dontReturnNull)   em System.Web.UI.Page.DeterminePostBackMode()   em System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

  Por outro lado, a falha de solicitação pode resultar na seguinte entrada num arquivo de log de IIS.

  #Campos: s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken 127.0.0.1 POST /webSite/Default.aspx - 80 - 127.0.0.1 - 500 0 0 1268

  Remover a solução alternativa: Para desfazer a solução alternativa, remova as seções de configuração que foram adicionadas à solução alternativa ou faça a restauração com um backup da configuração feito antes das soluções alternativas.

Qual é o escopo da vulnerabilidade? 
Essa é uma vulnerabilidade de negação de serviço (site em inglês). Essa vulnerabilidade torna viável o ataque de invasores não autenticados que degradam o desempenho de um site ASP.NET, criando uma condição de negação de serviço.

O que provoca a vulnerabilidade? 
A vulnerabilidade existe devido à maneira como os hashes ASP.NET especialmente criados solicitam e inserem esses dados em uma tabela de hash, causando uma colisão de hash. Quando muitas dessas colisões são encadeadas, o desempenho da tabela de hash fica muito ruim, o que leva à condição de negação de serviço.

Para que um invasor pode usar a vulnerabilidade? 
Um invasor pode usar essa vulnerabilidade para causar um ataque de negação de serviço e atrapalhar a disponibilidade de sites que usam ASP.NET.

De que forma o invasor pode explorar a vulnerabilidade? 
Um invasor não autenticado pode enviar um número pequeno de solicitações ASP.NET especialmente criadas para um site ASP.NET afetado, causando uma condição de negação de serviço.

Quais são os principais sistemas que correm riscos com a vulnerabilidade? 
Os sistemas que estão na Internet, com o ASP.NET instalado, estão principalmente correndo risco de apresentar essa vulnerabilidade. Além disso, os sites internos que usam a autenticação do ASP.NET Forms estão correndo risco de apresentar essa vulnerabilidade.

O que a atualização faz? 
A atualização aborda esta vulnerabilidade corrigindo como o .Net Framework manipula as solicitações específicas.

Quando esse boletim de segurança foi lançado, essa vulnerabilidade já tinha sido divulgada publicamente? 
Sim. Essa vulnerabilidade foi divulgada publicamente. Ela recebeu o número CVE-2011-3414 da lista Common Vulnerability and Exposure.

Quando este boletim de segurança foi lançado, a Microsoft tinha recebido algum relatório informando que essa vulnerabilidade estava sendo explorada? 
Não. A Microsoft não recebeu nenhuma informação indicando que essa vulnerabilidade tinha sido usada publicamente para atacar clientes quando este boletim de segurança foi lançado pela primeira vez.

Como isto afeta a indústria?
Os ataques a este tipo de vulnerabilidade são genericamente conhecidos como ataques de colisão de hash. Ataques como esses não são específicos às tecnologias da Microsoft e afetam outros fornecedores de software de serviço Web. Os clientes devem contatar seus fornecedores de plataforma Web para obter orientação ou atualizações.

A atenuação refere-se a uma configuração, configuração comum ou prática recomendada geral, existindo num estado padrão, que possa reduzir a gravidade de exploração de uma vulnerabilidade. Os fatores de atenuação a seguir podem ser úteis em sua situação:

• Essa vulnerabilidade não permite que um invasor execute códigos nem aumente seus direitos de usuário diretamente, mas ela pode ser usada para gerar informações que poderiam ser usadas para tentar comprometer ainda mais as informações do usuário.
• Por padrão, instalar o ASP.NET não habilita a Autenticação de Formulários. Isso deve ser explicitamente configurado em cada aplicativo.
• Por padrão, o IIS não está instalado.
• Por padrão, o ASP.NET não está instalado quando o .Net Framework estiver instalado. Somente os clientes que instalam e capacitam manualmente o ASP.NET estão provavelmente vulneráveis a este problema.
• O invasor teria que convencer o usuário a clicar em um link para explorar a vulnerabilidade.

A solução alternativa refere-se a uma configuração ou alteração de configuração que não corrige a vulnerabilidade subjacente mas que ajudaria a bloquear vetores de ataque conhecidos antes de aplicar a atualização. A Microsoft testou as soluções alternativas e estados a seguir como parte do cenário que implica se uma solução alternativa reduziria funcionalidade:

• Desabilitar a Autenticação de Formulário no web.config
  1. Abra o aplicativo ou arquivo global web.config depois de fazer uma cópia de backup
  2. Configure o modo de autenticação para Windows, Passaporte ou Nenhum.<system.web>  <authentication mode="Windows | Passport | None" /></system.web>Os detalhes de cada modo podem ser localizados em Como desfazer a solução alternativa.Restaure seu arquivo web.config da sua cópia de backup.

Qual é o escopo da vulnerabilidade? 
Essa é uma vulnerabilidade de falsificação. Esta vulnerabilidade podia capacitar um invasor a redirecionar um usuário para um site de escolha do invasor, sem o conhecimento do usuário. O invasor então podia executar um ataque de phishing para obter informações que os usuários não pretendiam divulgar. Esta vulnerabilidade não permitiria que um invasor executasse o código nem elevasse seus direitos de usuário diretamente, mas poderiam ser usado para comprometer ainda mais as informações que os usuários pretendiam manter em sigilo.

O que é phishing? 
O phishing (o "ph" é pronunciado com som de "f") online é uma maneira de descobrir informações pessoais ou financeiras dos usuários de computador, por meio de uma mensagem de email fraudulenta ou por meio de um site. Uma tentativa de phishing online comum inicia com uma mensagem de email que assemelha-se a um aviso oficial de uma fonte de confiança, tal como um banco, uma companhia de cartão de crédito, ou um comerciante on-line respeitável. Na mensagem de email, os destinatários são direcionados a um site fraudulento onde são solicitadas informações pessoais, tal como um número de conta ou senha. Esta informação é geralmente usada para roubo de identidade.

O que provoca a vulnerabilidade? 
Esta vulnerabilidade é causada quando o .Net Framework verifica incorretamente o retorno das URLs durante o processo de autenticação de formulários.

O que é Autenticação de Formulários no ASP.NET? 
A autenticação de formulários usa um ticket de autenticação que é criado quando um usuário faz logon em um site, e então controla o usuário por todo o site. O ticket de autenticação de formulários geralmente está contido dentro de um cookie. No entanto, o ASP.NET versão 2.0 oferece autenticação de formulários sem cookies, fazendo com o ticket passe por uma cadeia de caracteres de consulta. Para obter mais informações, consulte o artigo (em inglês) do MSDN, Explained: Forms Authentication in ASP.NET 2.0.

Para que um invasor pode usar a vulnerabilidade? 
Um invasor que explore com êxito esta vulnerabilidade poderia redirecionar um usuário a um site de escolha do invasor, sem o conhecimento do usuário. Esta vulnerabilidade não permitiria que um invasor executasse o código nem elevasse seus direitos de usuário diretamente, mas poderiam ser usado para comprometer ainda mais as informações que os usuários pretendiam manter em sigilo.

De que forma o invasor pode explorar a vulnerabilidade? 
Um invasor poderia criar uma URL especialmente criada e convencer um usuário para clicar nela. Depois que um usuário fizer logon em um site esperado, o invasor então redireciona o usuário a um site controlado pelo invasor. Então, o invasor poderia convencer o usuário a divulgar informações que deveriam permanecer sigilosas. Em todos os casos, entretanto, o invasor não tem como forçar os usuários a exibir o conteúdo controlado pelo invasor. Em vez disso, um invasor teria que convencer os usuários a tomar medidas, geralmente clicando em um link numa mensagem de email ou numa mensagem do Instant Messenger que direciona os usuários ao site do invasor depois de fazer logon em um site esperado.

Quais são os principais sistemas que correm riscos com a vulnerabilidade? 
Os sistemas que estão na Internet, com o ASP.NET instalado, estão principalmente correndo risco de apresentar essa vulnerabilidade. Além disso, os sites internos que usam a autenticação do ASP.NET Forms estão correndo risco de apresentar essa vulnerabilidade.

O que a atualização faz? 
A atualização elimina esta vulnerabilidade corrigindo a maneira que o .Net Framework verifica o retorno das URLs durante autenticação de formulários.

Quando esse boletim de segurança foi lançado, essa vulnerabilidade já tinha sido divulgada publicamente? 
Não. A Microsoft recebeu informações sobre esta vulnerabilidade por meio da divulgação coordenada de vulnerabilidades.

Quando este boletim de segurança foi lançado, a Microsoft tinha recebido algum relatório informando que essa vulnerabilidade estava sendo explorada? 
Não. A Microsoft não recebeu nenhuma informação indicando que essa vulnerabilidade tinha sido usada publicamente para atacar clientes quando este boletim de segurança foi lançado pela primeira vez.

A atenuação refere-se a uma configuração, configuração comum ou prática recomendada geral, existindo num estado padrão, que possa reduzir a gravidade de exploração de uma vulnerabilidade. Os fatores de atenuação a seguir podem ser úteis em sua situação:

• Um invasor deve ser capaz de registrar uma conta no aplicativo do ASP.NET, e deve saber um nome de usuário existente.
• Por padrão, instalar o ASP.NET não habilita a Autenticação de Formulários. Isso deve ser explicitamente configurado em cada aplicativo.
• Por padrão, o IIS não está instalado.
• Por padrão, o ASP.NET não está instalado quando o .NET estiver instalado. Somente os clientes que instalam e capacitam manualmente o ASP.NET estão provavelmente vulneráveis a este problema.

A solução alternativa refere-se a uma configuração ou alteração de configuração que não corrige a vulnerabilidade subjacente mas que ajudaria a bloquear vetores de ataque conhecidos antes de aplicar a atualização. A Microsoft testou as soluções alternativas e estados a seguir como parte do cenário que implica se uma solução alternativa reduziria funcionalidade:

• Configure o ticketCompatibilityMode para o Framework40

  Isso se aplica somente a sites que executam o ASP.NET 4 ou mais recente, pois a configuração ticketCompatibilityMode foi introduzida no ASP.NET v4.0.

  1. Abra o aplicativo ou arquivo global web.config depois de fazer uma cópia de backup
  2. Configure o ticketCompatibilityMode para o Framework40. Observe que o valor padrão para esta configuração é "Framework20"<system.web>  <authentication mode="Forms">    <forms ticketCompatibilityMode="Framework40" />  </authentication></system.web>

  Como desfazer a solução alternativa.

  Restaure seu arquivo web.config da sua cópia de backup.

• Desabilitar a Autenticação de Formulário no web.config
  1. Abra o aplicativo ou arquivo global web.config depois de fazer uma cópia de backup
  2. Configure o modo de autenticação para Windows, Passaporte ou Nenhum.<system.web>  <authentication mode="Windows | Passport | None" /></system.web>Os detalhes de cada modo podem ser localizados em Como desfazer a solução alternativa.Restaure seu arquivo web.config da sua cópia de backup.

Qual é o escopo da vulnerabilidade? 
Isto é uma elevação da vulnerabilidade de privilégio onde um invasor remoto não autenticado pode acessar a outra conta no aplicativo de ASP.NET, capacitando um invasor a executar os comandos arbitrários no site no contexto do usuário visado.

O que provoca a vulnerabilidade? 
Esta vulnerabilidade é causada quando o ASP.NET Framework autentica incorretamente os nomes de usuário especialmente criados.

Para que um invasor pode usar a vulnerabilidade? 
Um invasor que explore com êxito esta vulnerabilidade poderia tomar qualquer ação no contexto do usuário visado, inclusive executar comandos arbitrários no site.

De que forma o invasor pode explorar a vulnerabilidade? 
Para explorar esta vulnerabilidade, um invasor não autenticado primeiro deveria ter conhecimento de um nome existente de conta para personificar no site. O invasor poderia, então, criar uma solicitação especial de web usando um nome de conta previamente registrado para conseguir acessar essa conta. O invasor poderia, então, tomar qualquer ação no contexto do usuário visado, inclusive executar comandos arbitrários no site.

Quais são os principais sistemas que correm riscos com a vulnerabilidade? 
Os sistemas que estão na Internet, com o ASP.NET instalado, estão principalmente correndo risco de apresentar essa vulnerabilidade. Além disso, os sites internos que usam a autenticação do ASP.NET Forms estão correndo risco de apresentar essa vulnerabilidade.

Se meu site usa uma web farm, eu deverei atualizar todos os computadores na web farm? 
Sim. Esta atualização muda o formato do ticket de autenticação de formulário de tal maneira que fique incompatível com o formato anterior. Isso quer dizer que os tickets gerados com o novo comportamento não podem ser lidos por computadores com o comportamento antigo e vice versa. Os administradores cujos aplicativos usam autenticação baseada em formulários devem realizar etapas específicas ao implantar esta atualização de segurança, para assegurar que todos seus servidores mudem para o novo comportamento simultaneamente.

Para obter mais informações, consulte o artigo do Technet da Microsoft 2659968.

É possível atualizar os computadores na minha web farm um por vez, em vez de todos ao mesmo tempo? 
Sim. Se não é viável implantar o MS11-100 a todos os servidores numa determinada web farm simultaneamente, você pode configurar uma opção de compatibilidade no seu arquivo web.config ou machine.config antes de instalar a atualização, para forçar o comportamento velho depois que a atualização for instalada. A opção de compatibilidade a ser usada é a seguinte:

<appSettings>  <add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" /></appSettings>

Configurar esta opção permitirá que web farms com apenas algumas máquinas atualizadas continuem a funcionar corretamente. No entanto, é importante saber que os computadores com o conjunto de opção de configuração estarão num estado inseguro, e não irão se beneficiar da correção nesta atualização de segurança. Depois que o MS11-100 foi implementado a todos os computadores numa farm, a opção de configuração deve ser removida para que o novo comportamento de segurança seja capacitado.

Isto irá atualizar a configuração ticketCompatibilityMode da autenticação de formulários do meu site? 
Não. Desde que a correção nesta atualização de segurança altere o formato de tickets de autenticação de formulários, a configuração ticketCompatibilityMode não é mais suportada depois que o MS11-100 for instalado.

O que a atualização faz? 
A atualização elimina esta vulnerabilidade corrigindo a maneira que o ASP.NET Framework autentica os usuários.

Quando esse boletim de segurança foi lançado, essa vulnerabilidade já tinha sido divulgada publicamente? 
Não. A Microsoft recebeu informações sobre esta vulnerabilidade por meio da divulgação coordenada de vulnerabilidades.

Quando este boletim de segurança foi lançado, a Microsoft tinha recebido algum relatório informando que essa vulnerabilidade estava sendo explorada? 
Não. A Microsoft não recebeu nenhuma informação indicando que essa vulnerabilidade tinha sido usada publicamente para atacar clientes quando este boletim de segurança foi lançado pela primeira vez.

A atenuação refere-se a uma configuração, configuração comum ou prática recomendada geral, existindo num estado padrão, que possa reduzir a gravidade de exploração de uma vulnerabilidade. Os fatores de atenuação a seguir podem ser úteis em sua situação:

• Por padrão, as respostas do ASP.NET não são armazenadas no cache pelo OutputCache. O desenvolvedor do site tem que optar em armazenar no cache as saídas pela diretriz do OutputCache numa página.
• O invasor que explorar com êxito essa vulnerabilidade poderá obter os mesmos direitos que o usuário visado. Os usuários cujas contas são configuradas com poucos direitos de usuário no sistema correm menos riscos do que aqueles que possuem direitos administrativos.
• Por padrão, o IIS não estão instalado em nenhuma versão de sistema operacional afetada. Somente clientes que fazem a instalação manualmente isto são prováveis alvos deste problema.
• Por padrão, o ASP.NET não está instalado quando o .NET estiver instalado. Somente os clientes que instalam e capacitam manualmente o ASP.NET estão provavelmente vulneráveis a este problema.

A solução alternativa refere-se a uma configuração ou alteração de configuração que não corrige a vulnerabilidade subjacente mas que ajudaria a bloquear vetores de ataque conhecidos antes de aplicar a atualização. A Microsoft testou as soluções alternativas e estados a seguir como parte do cenário que implica se uma solução alternativa reduziria funcionalidade:

• Restrinja os cookies de autenticação de formulários para canais SSL

  Abra o aplicativo ou arquivo global web.config depois de fazer uma cópia de backup.

  Configure requireSSL =" true" no elemento <forms>, conforme mostrado no seguinte código.

  <forms loginUrl="Secure\Login.aspx"    requireSSL="true" />

  Como desfazer a solução alternativa.

  Restaure seu arquivo web.config da sua cópia de backup.

• Desabilite expiração móvel para cookies de autenticação de formulários
  1. Abra o aplicativo ou arquivo global web.config depois de fazer uma cópia de backup
  2. Configure slidingExpiration="false" no elemento <forms>, conforme mostrado no código a seguir.<forms slidingExpiration="false"/>

  Impacto da solução alternativa. Os usuários seriam forçados a fazer o logon novamente depois que seus tickets expirarem.

  Como desfazer a solução alternativa.

  Restaure seu arquivo web.config da sua cópia de backup.

• Desabilite o OutputCache
  1. Faça backup de sua pasta de aplicativo web.
  2. Remova todas as diretrizes <%@ OutputCache %> das suas páginas web.
  3. Se seu site é um aplicativo MVC, também remova todos os atributos de OutputCache de suas ações de controlador.

  Impacto da solução alternativa. Os usuários seriam forçados a fazer o logon novamente depois que seus tickets expirarem.

  Como desfazer a solução alternativa.

  Restaure sua pasta de aplicativos Web.

Qual é o escopo da vulnerabilidade? 
Isto é uma elevação de vulnerabilidade de privilégio onde um invasor obtém acesso remoto não autenticado a outra conta no aplicativo do .NET.

O que provoca a vulnerabilidade? 
Esta vulnerabilidade é causada quando o .Net Framework manipula incorretamente o conteúdo armazenado em cache quando a Autenticação de Formulários é usada com expiração móvel.

Para que um invasor pode usar a vulnerabilidade? 
Um invasor que explore com êxito esta vulnerabilidade poderia tomar qualquer ação, inclusive executar comandos arbitrários que o usuário podia realizar no site, no contexto do usuário visado.

De que forma o invasor pode explorar a vulnerabilidade? 
Em um cenário de ataque por email, o invasor pode explorar a vulnerabilidade enviando um link especialmente criado para o usuário e persuadindo-o a clicar no link. Não há como o invasor forçar os usuários a visitarem o site mal-intencionado. Em vez disso, um invasor teria que convencer os usuários a tomarem medidas, geralmente clicar em um link numa mensagem de e-mail ou em uma mensagem de Instant Messenger.

O que é Autenticação de Formulários no ASP.NET? 
A autenticação de formulários usa um ticket de autenticação que é criado quando um usuário faz logon em um site, e então controla o usuário por todo o site. O ticket de autenticação de formulários geralmente está contido dentro de um cookie. No entanto, o ASP.NET versão 2.0 oferece autenticação de formulários sem cookies, fazendo com o ticket passe por uma cadeia de caracteres de consulta. Para obter mais informações, consulte o artigo (em inglês) do MSDN, Explained: Forms Authentication in ASP.NET 2.0.

Quais são os principais sistemas que correm riscos com a vulnerabilidade? 
Os sistemas que estão na Internet, com o ASP.NET instalado, estão principalmente correndo risco de apresentar essa vulnerabilidade. Além disso, os sites internos que usam a autenticação do ASP.NET Forms estão correndo risco de apresentar essa vulnerabilidade.

O que a atualização faz? 
A atualização modifica a maneira que o ASP.NET manipula conteúdo armazenado em cache.

Quando esse boletim de segurança foi lançado, essa vulnerabilidade já tinha sido divulgada publicamente? 
Não. A Microsoft recebeu informações sobre esta vulnerabilidade por meio da divulgação coordenada de vulnerabilidades.

Quando este boletim de segurança foi lançado, a Microsoft tinha recebido algum relatório informando que essa vulnerabilidade estava sendo explorada? 
Não. A Microsoft não recebeu nenhuma informação indicando que essa vulnerabilidade tinha sido usada publicamente para atacar clientes quando este boletim de segurança foi lançado pela primeira vez.

Tabela de referência

A tabela a seguir contém as informações de atualização de segurança desse software. Você pode encontrar informações adicionais na subseção Informações de implantação, nesta seção.

Observação a atualização para as versões com suporte do Windows XP Professional x64 Edition também se aplica a versões suportadas do Windows Server 2003 x64 Edition.

Tabela de referência

A tabela a seguir contém as informações de atualização de segurança desse software. Você pode encontrar informações adicionais na subseção Informações de implantação, nesta seção.

Observação a atualização para as versões com suporte do Windows Server 2003 x64 Edition também se aplica a versões suportadas do Windows XP Professional x64 Edition.

Tabela de referência

A tabela a seguir contém as informações de atualização de segurança desse software. Você pode encontrar informações adicionais na subseção Informações de implantação, nesta seção.

Tabela de referência

A tabela a seguir contém as informações de atualização de segurança desse software. Você pode encontrar informações adicionais na subseção Informações de implantação, nesta seção.

Tabela de referência

A tabela a seguir contém as informações de atualização de segurança desse software. Você pode encontrar informações adicionais na subseção Informações de implantação, nesta seção.

Tabela de referência

A tabela a seguir contém as informações de atualização de segurança desse software. Você pode encontrar informações adicionais na subseção Informações de implantação, nesta seção.