Microsoft Security Bulletin MS11-100 - Crítica

O factor atenuante refere-se a uma definição, uma configuração comum ou uma prática recomendada geral, que existe num estado predefinido, que poderia reduzir a gravidade da exploração de uma vulnerabilidade. Os seguintes factores atenuantes podem ser úteis para a sua situação:

• Por predefinição, o IIS não está activado em nenhum sistema operativo Windows
• Os sites que desactivam tipos de conteúdo HTTP application/x-www-form-urlencoded ou multipart/form-data não estão vulneráveis
• Por predefinição, o ASP.NET não é instalado quando o .NET Framework é instalado. Apenas os clientes que instalem manualmente e activem o ASP.NET podem estar vulneráveis a este problema.

Uma solução alternativa refere-se a uma definição ou alteração de configuração que não corrige a vulnerabilidade subjacente, mas que ajudaria a bloquear vectores de ataque conhecidos antes de aplicar a actualização. A Microsoft testou as seguintes soluções alternativas e indica se a solução alternativa reduz a funcionalidade:

• Solução alternativa baseada em configuração

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

  Nota: Faça uma cópia de segurança da sua configuração antes de fazer alterações.

  Este valor de configuração pode ser aplicado globalmente a todos os sites ASP.NET num servidor adicionando a entrada à raiz web.config ou applicationhost.config. Em alternativa, esta configuração pode ser restringida a um determinado site ou aplicação adicionando-o(a) a um ficheiro web.config para o site ou aplicação em questão. Para mais informações sobre a configuração ASP.NET, consulte o artigo MSDN Visão Geral da Configuração ASP.NET.

  1. Se a sua aplicação utiliza ViewState, adicione a seguinte configuração no ficheiro de configuração ASP.NET adequado para limitar o tamanho máximo do pedido que o ASP.NET aceitará de um cliente para 200 KB.

     <configuration>
  <system.web>
  <httpRuntime maxRequestLength="200”/>
  </system.web>
</configuration>

  2. Se a sua aplicação não utiliza ASP.NET ViewState, adicione a seguinte configuração no ficheiro de configuração ASP.NET adequado para limitar o tamanho máximo do pedido que o ASP.NET aceitará de um cliente para 20 KB.

     <configuration>
  <system.web>
  <httpRuntime maxRequestLength="20”/>
  </system.web>
</configuration>

  Para mais informações sobre a opção de configuração maxRequestLength, consulte a documentação MSDN sobre o Elemento httpRuntime.

  Nota: Aumentar a cadeia de consulta HTTP predefinida e solicitar limites para o tamanho de cabeçalho aumentará a susceptibilidade do servidor em relação à questão de negação de serviço descrita neste aviso. Para mais informações sobre como definir estes limites, consulte Definições de registo Http.sys para IIS.

  Impacto da solução alternativa: Os pedidos do cliente que excedam o maxRequestLength configurado irão resultar num ConfigurationErrorsException no lado do servidor e num estado de erro http devolvido ao cliente. Os limites configurados anteriormente devem ser utilizados como um ponto de partida e podem ser ajustados para evitar falhas de aplicação. Configurar o valor maxRequestLength para um valor inferior também reduz a susceptibilidade do servidor em relação a esta negação de serviço. As aplicações que aceitam carregamentos de ficheiros do cliente e as aplicações que geram um grande viewstate são exemplos de aplicações que podem ser afectadas por esta solução alternativa.

  Depois de aplicar esta solução alternativa, pode aparecer a seguinte falha no pedido do cliente no registo de eventos de Aplicação.

  Código de evento: 3004
Mensagem de evento: O tamanho de post excedeu os limites permitidos.
Informação de excepção:
    Tipo de excepção: HttpException
    Mensagem de excepção: Comprimento máximo do pedido 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)

  Em alternativa, a falha no pedido pode resultar na seguinte entrada num ficheiro de registo 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

  Remoção da solução alternativa: Para anular a solução alternativa, remova as secções de configuração que foram adicionadas nesta solução alternativa ou reverta para uma cópia de segurança da configuração anterior às soluções alternativas.

Qual é a abrangência desta vulnerabilidade? 
Esta é uma vulnerabilidade de negação de serviço. Esta vulnerabilidade permite que um intruso não autenticado diminua 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 à forma como o ASP.NET faz hash de pedidos especialmente concebidos para o efeito e insere esses dados numa tabela de hash causando uma colisão de hash. Quando muitas destas colisões são encadeado em conjunto, o desempenho da tabela de hash diminui bastante levando à condição de negação de serviço.

Como poderia um intruso utilizar a vulnerabilidade? 
Um intruso poderia utilizar esta vulnerabilidade para causar um ataque de negação de serviço e causar a ruptura de disponibilidade de sites que utilizam ASP.NET.

Como poderia um intruso explorar a vulnerabilidade? 
Um intruso não autenticado poderia enviar um pequeno número de pedidos ASP.NET especialmente concebidos a um site ASP.NET afectado, causando uma condição de negação de serviço.

Quais os sistemas mais susceptíveis a esta vulnerabilidade? 
Os sistemas mais susceptíveis a este risco são sistemas voltados para a Internet com o ASP.NET instalado. Além disso, Web sites internos que usam a autenticação de formulários ASP.NET podem estar susceptíveis a esta vulnerabilidade.

O que faz a actualização? 
A actualização resolve esta vulnerabilidade corrigindo a forma como o .NET Framework processa pedidos especialmente concebidos para o efeito.

Quando este boletim de segurança foi publicado, esta vulnerabilidade já tinha sido divulgada publicamente? 
Sim. Esta vulnerabilidade foi divulgada publicamente. Foi-lhe atribuído o número de Vulnerabilidade e Exposição Comum CVE-2011-3414.

Quando este boletim de segurança foi publicado, a Microsoft já tinha recebido informações sobre a exploração desta vulnerabilidade? 
Não. A Microsoft ainda não tinha recebido informações que indicassem que esta vulnerabilidade tivesse sido utilizada publicamente para atacar clientes, quando este boletim de segurança foi publicado pela primeira vez.

De que forma este é um problema da indústria?
Os ataques que visam este tipo de vulnerabilidade são genericamente conhecidos como ataques de colisão de hash. Ataques como estes não são específicos às tecnologias Microsoft e afectam outros fornecedores de software de serviço Web. Os clientes devem contactar os seus fornecedores de plataformas da Web para obterem orientação ou actualizações.

O factor atenuante refere-se a uma definição, uma configuração comum ou uma prática recomendada geral, que existe num estado predefinido, que poderia reduzir a gravidade da exploração de uma vulnerabilidade. Os seguintes factores atenuantes podem ser úteis para a sua situação:

• Esta vulnerabilidade não permitiria que um intruso executasse código ou elevasse directamente os seus privilégios de utilizador, mas poderia ser utilizada para produzir informações que poderiam ser usadas para comprometer ainda mais as informações do utilizador.
• Por predefinição, instalar o ASP.NET não activa a Autenticação de Formulários. Tem de ser explicitamente configurada por aplicação para ser activada.
• Por predefinição, o IIS não é instalado.
• Por predefinição, o ASP.NET não é instalado quando o .NET Framework é instalado. Apenas os clientes que instalem manualmente e activem o ASP.NET podem estar vulneráveis a este problema.
• O intruso teria de convencer o utilizador a clicar numa ligação para explorar a vulnerabilidade.

Uma solução alternativa refere-se a uma definição ou alteração de configuração que não corrige a vulnerabilidade subjacente, mas que ajudaria a bloquear vectores de ataque conhecidos antes de aplicar a actualização. A Microsoft testou as seguintes soluções alternativas e indica se a solução alternativa reduz a funcionalidade:

• Desactivar a Autenticação de Formulários em web.config
  1. Abra a aplicação ou o ficheiro global web.config depois de ter feito uma cópia de segurança
  2. Defina o modo de autenticação para Windows, Passaporte ou Nenhum.

     <system.web>

       <authentication mode="Windows | Passport | None" />

     </system.web>

     Pode encontrar os detalhes de cada modo em http://msdn.microsoft.com/en-us/library/aa291347(v=vs.71).aspx.

     Como anular esta solução alternativa. 

     Restaure o ficheiro web.config da sua cópia de segurança.

Qual é a abrangência desta vulnerabilidade? 
Esta é uma vulnerabilidade de spoofing. Esta vulnerabilidade poderia permitir que um intruso redireccionasse um utilizador para um Web site seleccionado pelo intruso sem o conhecimento do utilizador. O intruso poderia então executar um ataque de phishing para obter informações do utilizador que este não pretendia divulgar. Esta vulnerabilidade não permitiria que um intruso executasse código nem elevasse directamente os seus direitos de utilizador, mas poderia ser utilizada para comprometer informações que o utilizador pretendia que permanecessem privadas.

O que é phishing? 
O phishing online é uma forma de enganar os utilizadores de sistemas informáticos no sentido de revelarem informações pessoais ou financeiras através de uma mensagem de correio electrónico fraudulenta ou Web site. Um esquema de phishing online comum começa com uma mensagem de correio electrónico semelhante a um aviso oficial de uma origem fidedigna, como um banco, uma empresa de cartões de crédito ou comerciantes online fidedignos. Na mensagem de correio electrónico, os destinatários são direccionados para um Web site fraudulento onde lhes é solicitado o fornecimento de informações pessoais, como um número de conta ou palavra-passe. Estas informações são geralmente utilizadas para roubo de identidade.

O que provoca a vulnerabilidade? 
Esta vulnerabilidade é causada quando o .NET Framework verifica incorrectamente URLs de regresso durante o processo de autenticação de formulários.

O que é a Autenticação de Formulários no ASP.NET? 
A autenticação de formulários utiliza uma permissão de autenticação que é criada quando um utilizador inicia sessão num site e rastreia o utilizador no site. A permissão de autenticação de formulários encontra-se geralmente no interior de um cookie. No entanto, a versão 2.0 do ASP.NET suporta autenticação de formulários sem cookies, o que faz com que a permissão seja transmitida numa cadeia de consulta. Para mais informações, consulte o artigo MSDN, Explicação: Autenticação de Formulários no ASP.NET 2.0.

Como poderia um intruso utilizar a vulnerabilidade? 
Um intruso que explorasse esta vulnerabilidade com sucesso poderia redireccionar um utilizador para um Web site seleccionado pelo intruso sem o conhecimento do utilizador. Esta vulnerabilidade não permitiria que um intruso executasse código nem elevasse directamente os seus direitos de utilizador, mas poderia ser utilizada para comprometer informações que o utilizador pretendia que permanecessem privadas.

Como poderia um intruso explorar a vulnerabilidade? 
Um intruso poderia criar um URL especialmente concebido para o efeito e convencer um utilizador a clicar nele. Depois de um utilizador iniciar sessão num Web site esperado, o intruso redirecciona o utilizador para um Web site controlado pelo intruso. Aí, o intruso poderia convencer o utilizador a divulgar informações que pretendia que permanecessem privadas. Contudo, em qualquer dos casos, o intruso não teria forma de forçar os utilizadores a visualizar o conteúdo controlado pelo intruso. Em vez disso, um intruso teria de convencer os utilizadores a executarem acções, geralmente clicando numa ligação numa mensagem de correio electrónico ou numa mensagem num programa de mensagens instantâneas que direcciona os utilizadores para o Web site do intruso depois de iniciar sessão num Web site esperado.

Quais os sistemas mais susceptíveis a esta vulnerabilidade? 
Os sistemas mais susceptíveis a este risco são sistemas voltados para a Internet com o ASP.NET instalado. Além disso, Web sites internos que usam a autenticação de formulários ASP.NET podem estar susceptíveis a esta vulnerabilidade.

O que faz a actualização? 
A actualização resolve esta vulnerabilidade corrigindo a forma como o .NET Framework verifica URLs de regresso durante a autenticação de formulários.

Quando este boletim de segurança foi publicado, esta vulnerabilidade já tinha sido divulgada publicamente? 
Não. A Microsoft recebeu informações sobre esta vulnerabilidade através de divulgação coordenada de vulnerabilidades.

Quando este boletim de segurança foi publicado, a Microsoft já tinha recebido informações sobre a exploração desta vulnerabilidade? 
Não. A Microsoft ainda não tinha recebido informações que indicassem que esta vulnerabilidade tivesse sido utilizada publicamente para atacar clientes, quando este boletim de segurança foi publicado pela primeira vez.

O factor atenuante refere-se a uma definição, uma configuração comum ou uma prática recomendada geral, que existe num estado predefinido, que poderia reduzir a gravidade da exploração de uma vulnerabilidade. Os seguintes factores atenuantes podem ser úteis para a sua situação:

• Um intruso tem de poder registar uma conta na aplicação ASP.NET e tem de conhecer um nome de utilizador existente.
• Por predefinição, instalar o ASP.NET não activa a Autenticação de Formulários. Tem de ser explicitamente configurada por aplicação para ser activada.
• Por predefinição, o IIS não é instalado.
• Por predefinição, o ASP.NET não é instalado quando o .NET é instalado. Apenas os clientes que instalem manualmente e activem o ASP.NET podem estar vulneráveis a este problema.

Uma solução alternativa refere-se a uma definição ou alteração de configuração que não corrige a vulnerabilidade subjacente, mas que ajudaria a bloquear vectores de ataque conhecidos antes de aplicar a actualização. A Microsoft testou as seguintes soluções alternativas e indica se a solução alternativa reduz a funcionalidade:

• Definir ticketCompatibilityMode para Framework40

  Esta acção aplica-se apenas a sites que executam o ASP.NET 4 e versões mais recentes, uma vez que a definição de ticketCompatibilityMode foi introduzida no ASP.NET v4.0.

  1. Abra a aplicação ou o ficheiro global web.config depois de ter feito uma cópia de segurança
  2. Defina o ticketCompatibilityMode para o Framework40. Note que o valor predefinido para esta definição é "Framework20"

     <system.web>
  <authentication mode="Forms">
    <forms ticketCompatibilityMode="Framework40" />
  </authentication>
</system.web>

  Como anular esta solução alternativa. 

  Restaure o ficheiro web.config da sua cópia de segurança.

• Desactivar a Autenticação de Formulários em web.config
  1. Abra a aplicação ou o ficheiro global web.config depois de ter feito uma cópia de segurança
  2. Defina o modo de autenticação para Windows, Passaporte ou Nenhum.

     <system.web>

       <authentication mode="Windows | Passport | None" />

     </system.web>

     Pode encontrar os detalhes de cada modo em http://msdn.microsoft.com/en-us/library/aa291347(v=vs.71).aspx.

     Como anular esta solução alternativa. 

     Restaure o ficheiro web.config da sua cópia de segurança.

Qual é a abrangência desta vulnerabilidade? 
Esta é uma vulnerabilidade de elevação de privilégios em que um intruso remoto não autenticado pode obter acesso a outra conta na aplicação ASP.NET, permitindo que um intruso execute comandos arbitrários no site no contexto do utilizador visado.

O que provoca a vulnerabilidade? 
Esta vulnerabilidade é causada quando o ASP.NET Framework autentica incorrectamente nomes de utilizador especialmente concebidos para o efeito.

Como poderia um intruso utilizar a vulnerabilidade? 
Um intruso que explorasse esta vulnerabilidade com sucesso poderia executar qualquer acção no contexto do utilizador visado, incluindo executar comandos arbitrários no site.

Como poderia um intruso explorar a vulnerabilidade? 
Para explorar esta vulnerabilidade, um intruso não autenticado teria de conhecer um nome de conta existente para se fazer passar por esse utilizador no site. O intruso poderia então criar um pedido Web especial utilizando um nome de conta anteriormente registado para aceder a essa conta. O intruso poderia então executar qualquer acção no contexto do utilizador visado, incluindo executar comandos arbitrários no site.

Quais os sistemas mais susceptíveis a esta vulnerabilidade? 
Os sistemas mais susceptíveis a este risco são sistemas voltados para a Internet com o ASP.NET instalado. Além disso, Web sites internos que usam a autenticação de formulários ASP.NET podem estar susceptíveis a esta vulnerabilidade.

Se o meu Web site utilizar uma Web farm, tenho de actualizar todos os computadores na Web farm? 
Sim. Esta actualização altera o formato da permissão de autenticação de formulários de uma forma que é incompatível com o formato anterior. Isto quer dizer que as permissões geradas utilizando o novo comportamento não podem ser lidas por computadores que utilizem o comportamento anterior e vice-versa. Os administradores cujas aplicações utilizem autenticação baseada em formulários devem seguir passos específicos ao implementar esta actualização de segurança de modo a assegurar que todos os seus servidores passam para o novo comportamento em simultâneo.

Para mais informações, consulte o Artigo da Microsoft TechNet 2659968.

É possível actualizar os computadores na minha Web farm individualmente em vez de a actualização ser feita em todos ao mesmo tempo? 
Sim. Se não for possível implementar simultaneamente o MS11-100 em todos os servidores numa determinada Web farm, pode definir um parâmetro de compatibilidade no ficheiro web.config ou machine.config antes de instalar a actualização para forçar o comportamento antigo depois de a actualização ser instalada. O parâmetro de compatibilidade a utilizar é o seguinte:

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

Definir este parâmetro permitirá que as Web farms com apenas algumas máquinas actualizadas continuem a funcionar correctamente. No entanto, é importante saber que computadores com a definição do parâmetro de configuração estarão num estado sem segurança e não beneficiarão da correcção nesta actualização de segurança. Depois de o MS11-100 ser implementado em todos os computadores numa farm, o parâmetro de configuração deve ser retirado para activar o novo comportamento seguro.

Esta actualização respeita a definição de autenticação de formulários ticketCompatibilityMode do meu site? 
Não. Uma vez que a correcção nesta actualização de segurança altera o formato das permissões de autenticação de formulários, a definição de configuração ticketCompatibilityMode deixa de ser suportada assim que o MS11-100 é instalado.

O que faz a actualização? 
A actualização resolve esta vulnerabilidade corrigindo a forma como o ASP.NET Framework autentica utilizadores.

Quando este boletim de segurança foi publicado, esta vulnerabilidade já tinha sido divulgada publicamente? 
Não. A Microsoft recebeu informações sobre esta vulnerabilidade através de divulgação coordenada de vulnerabilidades.

Quando este boletim de segurança foi publicado, a Microsoft já tinha recebido informações sobre a exploração desta vulnerabilidade? 
Não. A Microsoft ainda não tinha recebido informações que indicassem que esta vulnerabilidade tivesse sido utilizada publicamente para atacar clientes, quando este boletim de segurança foi publicado pela primeira vez.

O factor atenuante refere-se a uma definição, uma configuração comum ou uma prática recomendada geral, que existe num estado predefinido, que poderia reduzir a gravidade da exploração de uma vulnerabilidade. Os seguintes factores atenuantes podem ser úteis para a sua situação:

• Por predefinição, as respostas ASP.NET não são guardadas em cache pela OutputCache. O programador do site tem de optar pelo processamento de cache através da directiva OutputCache numa página.
• Um intruso que conseguisse explorar esta vulnerabilidade com sucesso poderia obter os mesmos privilégios que o utilizador visado. Os utilizadores cujas contas estão configuradas com menos direitos de utilização no sistema podem correr menos riscos do que os utilizadores que trabalham com direitos de utilização de administrador.
• Por predefinição, o IIS não está instalado em nenhuma das versões dos sistemas operativos afectados. Apenas os clientes que instalaram manualmente poderão estar vulneráveis a esta questão.
• Por predefinição, o ASP.NET não é instalado quando o .NET é instalado. Apenas os clientes que instalem manualmente e activem o ASP.NET podem estar vulneráveis a este problema.

Uma solução alternativa refere-se a uma definição ou alteração de configuração que não corrige a vulnerabilidade subjacente, mas que ajudaria a bloquear vectores de ataque conhecidos antes de aplicar a actualização. A Microsoft testou as seguintes soluções alternativas e indica se a solução alternativa reduz a funcionalidade:

• Restringir cookies de autenticação de formulários em canais SSL

  Abra a aplicação ou o ficheiro global web.config depois de ter feito uma cópia de segurança.

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

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

  Como anular esta solução alternativa. 

  Restaure o ficheiro web.config da sua cópia de segurança.

• Desactive a expiração ajustável para cookies de autenticação de formulários
  1. Abra a aplicação ou o ficheiro global web.config depois de ter feito uma cópia de segurança
  2. Defina slidingExpiration="false" no elemento <forms>, conforme apresentado no seguinte código.

     <forms slidingExpiration="false"/>

  Impacto da solução alternativa. Os utilizadores seriam forçados a voltar a iniciar sessão depois de as suas permissões expirarem.

  Como anular esta solução alternativa. 

  Restaure o ficheiro web.config da sua cópia de segurança.

• Desactivar a OutputCache
  1. Crie uma cópia de segurança da pasta de aplicações Web.
  2. Retire todas as directivas <%@ OutputCache %> nas suas páginas Web.
  3. Se o seu Web site é uma aplicação MVC, retire também todos os atributos OutputCache das suas acções de controlador.

  Impacto da solução alternativa. Os utilizadores seriam forçados a voltar a iniciar sessão depois de as suas permissões expirarem.

  Como anular esta solução alternativa. 

  Restaure a sua pasta de aplicações Web.

Qual é a abrangência desta vulnerabilidade? 
Esta é uma vulnerabilidade de elevação de privilégios em que um intruso remoto não autenticado consegue aceder a outra conta na aplicação .NET.

O que provoca a vulnerabilidade? 
Esta vulnerabilidade é causada quando o .NET Framework processa incorrectamente conteúdos guardados em cache quando a Autenticação de Formulários é utilizada com expiração ajustável.

Como poderia um intruso utilizar a vulnerabilidade? 
Um intruso que explorasse esta vulnerabilidade com sucesso poderia executar qualquer acção que o utilizador executasse no site no contexto do utilizador visado, incluindo executar comandos arbitrários.

Como poderia um intruso explorar a vulnerabilidade? 
Num cenário de ataque com base em correio electrónico, um intruso poderia explorar a vulnerabilidade enviando uma ligação especialmente concebida para o efeito ao utilizador e convencendo-o a clicar nessa ligação. Um intruso não teria como obrigar os utilizadores a visitar o Web site. Em vez disso, um intruso teria de convencer os utilizadores a executarem acções, geralmente clicando numa ligação numa mensagem de correio electrónico ou numa mensagem num programa de mensagens instantâneas.

O que é a Autenticação de Formulários no ASP.NET? 
A autenticação de formulários utiliza uma permissão de autenticação que é criada quando um utilizador inicia sessão num site e rastreia o utilizador no site. A permissão de autenticação de formulários encontra-se geralmente no interior de um cookie. No entanto, a versão 2.0 do ASP.NET suporta autenticação de formulários sem cookies, o que faz com que a permissão seja transmitida numa cadeia de consulta. Para mais informações, consulte o artigo MSDN, Explicação: Autenticação de Formulários no ASP.NET 2.0.

Quais os sistemas mais susceptíveis a esta vulnerabilidade? 
Os sistemas mais susceptíveis a este risco são sistemas voltados para a Internet com o IIS e o ASP.NET instalado. Além disso, Web sites internos que usam a autenticação de formulários ASP.NET podem estar susceptíveis a esta vulnerabilidade.

O que faz a actualização? 
A actualização resolve a forma como o ASP.NET processa conteúdos guardados em cache.

Quando este boletim de segurança foi publicado, esta vulnerabilidade já tinha sido divulgada publicamente? 
Não. A Microsoft recebeu informações sobre esta vulnerabilidade através de divulgação coordenada de vulnerabilidades.

Quando este boletim de segurança foi publicado, a Microsoft já tinha recebido informações sobre a exploração desta vulnerabilidade? 
Não. A Microsoft ainda não tinha recebido informações que indicassem que esta vulnerabilidade tivesse sido utilizada publicamente para atacar clientes, quando este boletim de segurança foi publicado pela primeira vez.

Tabela de referência

A tabela seguinte contém a informação sobre a actualização de segurança para este software. Pode encontrar informações adicionais na subsecção Informações de Implementação, nesta secção.

Nota A actualização para versões suportadas 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 seguinte contém a informação sobre a actualização de segurança para este software. Pode encontrar informações adicionais na subsecção Informações de Implementação, nesta secção.

Nota A actualização para versões suportadas 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 seguinte contém a informação sobre a actualização de segurança para este software. Pode encontrar informações adicionais na subsecção Informações de Implementação, nesta secção.

Tabela de referência

A tabela seguinte contém a informação sobre a actualização de segurança para este software. Pode encontrar informações adicionais na subsecção Informações de Implementação, nesta secção.

Tabela de referência

A tabela seguinte contém a informação sobre a actualização de segurança para este software. Pode encontrar informações adicionais na subsecção Informações de Implementação, nesta secção.

Tabela de referência

A tabela seguinte contém a informação sobre a actualização de segurança para este software. Pode encontrar informações adicionais na subsecção Informações de Implementação, nesta secção.