A Ciência da Criação de Patches de Segurança

Uma das melhores coisas do meu trabalho é que eu estou constantemente trabalhando com clientes. Nadamelhor do que estar com gente que usa os nossos produtos no dia a dia para aprender e obter feedback sobre como a Microsoft deveria agir e como poderíamos fazer melhor o nosso trabalho. Mais especificamente sobre o nosso processo de divulgação de correções de segurança, este feedback que eu recebo de clientes invariavelmente é:

1. "O patch não pode afetar negativamente as minhas aplicações e os meus serviços."

2. "Quanto menos patches melhor. Especialmente menos patches que precisem de reboot."

3. "Quero saber quando vocês vão divulgar patches de segurança. Eu preciso estar preparado."

Mas "Não quero que os meus sistemas estejam desprotegidos contra uma vulnerabilidade conhecida".

O problema é que estes são requisitos intrinsicamente conflitantes entre si. Por exemplo, a única forma de evitar que uma correção cause problemas em outras aplicações é testar exaustivamente o patch. Em uma correção no Windows como a MS07-017 a Microsoft testa não só todas as suas próprias aplicações como também as outras principais aplicações no mercado, inclusive as de código aberto. Caso um problema seja encontrado o patch tem que ser alterado para contornar este problema, ou uma correção adicional tem que ser preparada, ou o fabricante é contactado para fazer uma alteração no seu produto. E o teste recomeça de novo, do zero. Em um certo ponto o patch MS07-017 tinha 80 potenciais problemas identificados.

Para diminuir o número de patches a Microsoft procura agregar se possível a correção de diversas vulnerabilidades em um único patch. Distribuir um patch custa dinheiro não só para a Microsoft mas principalmente para os clientes. O CSO de uma grande indústria automobilística uma vez nos disse que cada patch do Windows custava para ele 200 mil dólares em pessoal, softwares de distribuição e teste e em downtime. O patch MS07-017 corrige 6 outras vulnerabilidades além do problema nos cursores animados, e das correções estarem agregadas provavelmente economizou um milhão de dólares só neste cliente.

Ao corrigir uma vulnerabilidade a Microsoft também verifica se o mesmo problema aparece em outras partes do código do produto, e mesmo em outras partes do código de outros produtos. Nada pior do que um patch não corrigir totalmente o problema e um novo outro patch ter que ser instalado.

Por fim, um feedback praticamente unânime foi tornar o processo previsível. Ao fixar a data de divulgação na segunda terça-feira de cada mês, a Microsoft permite que as empresas aloquem recursos, preparem laboratório para testes, estabeleçam janelas de manutenção, etc. para otimizar o seu próprio processo de gerência de patches. Na verdade eu não conheço um único cliente que queira voltar para a situação anterior, onde o patch era divulgado no dia e horário em que ficava pronto.

Testar exaustivamente um patch, agregá-los várias vulnerabilidades em uma única correção, esperar o dia certo para a divulgação, tudo isto demora tempo e joga contra o desejo de ter a correção o mais rápido possível. A Microsoft tem que achar um ponto de equilíbrio entre prioridades que conflitam entre si, e tomar decisões que nem sempre vão agradar a todos. O MSRC procura adotar as seguintes diretivas:

¦ Nenhum patch vai ser divulgado sem passar pelo conjunto de testes de qualidade.

¦ O patch vai ser divulgado fora do seu ciclo normal se clientes estiverem em risco imediato de um ataque.

No caso da vulnerabilidade de cursores animados, ela foi reportada para a Microsoft no final de Dezembro, e a correção em si do problema é normalmente a coisa mais rápida de todo o processo. Em seguida a correção foi empacotado em um patch com outras vulnerabilidades que afetavam a win32k.sys e user32.dll, testado exaustivamente, e estava pronto para ser lançado no próximo dia 10 de Abril. Como a vulnerabilidade foi descoberta de forma independente e estava sendo ativamente explorada, a divulgação foi antecipada para o ontem (3/4).

A falha da Microsoft, é claro, foi deixar que a vulnerabilidade existisse no seu produto. Aqui no nosso processo SDL falhou, e é uma oportunidade para aprender e melhorar o processo. Mas no processo de lançamento de patches acho que a empresa agiu corretamente. Algumas pessoas acham um absurdo um problema reportado em Dezembro ser corrigido somente em Abril - mais eu acho que mais importante do que isso é ter um patch de qualidade, e se a vulnerabilidade não está sendo explorada publicamente existe tempo para tentar garantir isso. A EEye por exemplo fez um patch em tempo recorde, mas o depois se confirmou que ele não resolvia o problema (havia um vetor de ataque que não fora corrigido). A Microsoft não pode correr o risco de divulgar uma correção que não resolva o problema ou que destrua uma aplicação popular, e para isso é necessário tempo.

Comments

• Anonymous
  January 01, 2003
  Claro Jorge. Whatever.  

• Anonymous
  January 01, 2003
  Oi Ricardo, Acho que não sigo a sua lógica aqui. Você está dizendo que a Microsoft espera propositalmente para lançar patches para forçar as pessoas a comprarem o Antigen? Dificil responder a algo assim. Mas já para contrapor à sua lógica: antivirus e IPSes não são alternativa para um patch. Antivirus e IPSes podem proteger o sistema contra exploits específicos, mas não corrigem a vulnerabilidade. Sem um patch o sistema continua vulnerável a ataques usando um outro exploit. Por exemplo, na vulnerabilidade envolvendo os arquivos WMF (MS06-001), existem praticamente infinitas formas de se construir um exploit. Os antivirus conseguiram criar assinaturas para parar os ataques conhecidos, mas era relativamente trivial mudar o o exploit para burlar essa proteção e realizar o ataque. O mesmo aconteceu no recente ataque usando arquivos ANI (MS07-017). Outro ponto onde não concordamos é quando você diz que os quatro meses são a janela de vulnerabilidade para o cliente. Na verdade a janela de vulnerabilidade só começa quando o ataque foi publicamente divulgado, ou usado como 0-day. Antes disso ela era conhecida somente pela Microsoft e pela Determina, e o fato de uma vulnerabilidade não ser pública muda muito o nível de risco que os clientes correm. Por fim, agradeço o seu feedback que os patches deveriam ser liberados tão logo estejam prontos. Infelizmente essa opinião parece ser minoritária entre os nossos clientes, que em peso nos dizem que preferem uma agenda mensal (na verdade, alguns deles já me disseram que prefeririam a cada três meses, como faz a Oracle). Abracos, - Fernando Cima

• Anonymous
  January 01, 2003
  Ricardo, Em resumo, você acha que a Microsoft demora propositalmente a lançar os patches para poder vender antivirus. E está claro que não há nada que eu possa falar que vá te convencer do contrário.  

• Anonymous
  January 01, 2003
  Caro Ricardo, a Microsoft compartilha com todos os fabricantes de antivirus informações sobre malware e exploits, dentro da Virus Information Alliance (http://www.microsoft.com/technet/security/alerts/info/via.mspx). Nao existe qualquer vantagem nesse ponto da Microsoft sobre os demais fabricantes. Por sinal a filosofia do Antigen é usar múltiplas engines de AV diferentes, de diversos fornecedores, trabalhando em paralelo.  Continuo sem entender porque você você menciona o Antigen quando fala de patches - eu não vejo a menor relação entre uma coisa e outra. O que impede um cliente de aplicar trimestralmente os patches é que, no momento em que um patch é divulgado, começa no underground o trabalho de engenharia reversa do patch e criaçao de exploits. Algumas poucas vulnerabilidades são 0-day e para elas os exploits já existem mesmo antes da divulgação do patch, mas a grande maioria (90%+) são vulnerabilidades reportadas de forma privada e que só se tornam públicas no lançamento do boletim.

• Anonymous
  April 05, 2007
  Cima, eu particularmente não acho que o SDL falhou, pois, ele preve uma fase de resposta. É inevitável que problemas no desenvolvimento aconteçam. Por mais que seja investido em processos, eles irão acontecer. Para isso uma boa estratégia de resposta deve atender, e eu tenho visto funcionar muito bem na microsoft.

• Anonymous
  April 12, 2007
  A Microsoft está trilhando o caminho da segurança - mas iniciou a caminhada bastante tarde e quando seus produtos já estavam grandes demais - por isto caminha lentamente. Concordo que ela não pode errar, e seus argumentos de complexidade e testes necessarios para evitar problemas sao válidos como defesa (ainda bem que existem patches rápidos alternativos!). Porém nada atenua o fato de apesar do "patrão" ter dado prioridade para a Segurança na MS, na realidade ficaremos esperando o dia em que os sistemas operacionais desta serão equiparáveis à segurança de um OpenBSD, por exemplo. As movimentações tardias da MS para reduzir o número de componentes disponíveis em versões de servidores é válida, mas mais uma vez tardia demais. No âmbito do usuário final, a educação e o que já sofremos com Worms e perdas financeiras causadas pela lentidão da Microsoft em corrigir seus problemas de segurança foram muito mais úteis para evitar novos problemas que as novas "funcionalidades" de segurança que já existem em outros sistemas operacionais superiores há décadas. Jorge Paranhos.

• Anonymous
  April 16, 2007
  Cima, concordo que patches deveriam ser testados antes de entrar em producao, mas veja a questao por outro lado. Voce, em outro post, criticou as empresas que investem em IPSes sem ter um processo de gerenciamento de patches,  mas qual a alternativa para uma empresa que tem que esperar 4 meses para primeiro ter algum patch para gerenciar? Veja, 4 meses nao é uma janela de vulnerabilidade (para o cliente), é uma janela  de capitalizacao (para o fornecedor). Se 200 mil sao gastos para testar um patch, quanto é arrecadado em 4 meses com licencas de ferramentas anti-malware? Liberação mensal  de patches é um processo que só beneficia empresas de <a href="http://www.microsoft.com/antigen/">antivirus.</a> Um mes de assinatura de antivírus deve ser o tempo necessario para recuperar o que (o  fornecedor) gasta com manutenção de segurança. Acho que os patches deveriam ser liberados tão logo estejam prontos. Nao sao todas as correcoes que demoram um mes para ser testadas. Cada um que decida quando os instalar de acordo com seus processos internos.

• Anonymous
  April 17, 2007
  >Você está dizendo que a Microsoft espera >propositalmente para lançar patches para forçar as >pessoas a comprarem o Antigen? >Mas já para contrapor à sua lógica: antivirus e IPSes >não são alternativa para um patch. >Sem um patch o sistema continua vulnerável a ataques >usando um outro exploit. Cima, acho que voce ja respondeu a tua propria pergunta. Se nao ha patches para corrigir o problema definitivamente, so resta apelar para pseudo-solucoes. E é ai que entra o Antigen nessa estrategia, que alias tem uma vantagem sobre os concorrentes porque o fornecedor sabe exatamente como se manifesta o problema para criar a assinatura enquanto desenvolve o patch. Quanto a agenda de correcoes, realmente nao entendo. Se o cliente quer um cliclo trimestral, o que impede que aplique somente trimestralmente as corrrecoes liberadas pela MS mensalmente? A unica explicacao é que crackers poderiam criar exploits se baseando no boletim da MS. Bem, qual o percentual de vulnerabilidades publicas baseadas em boletins e qual o percentual baseado em 'pesquisa propria'?

• Anonymous
  April 19, 2007
  The comment has been removed