Gerenciamento de Segurança - Maio de 2005
Segurança em Operação (3/4): Atualizações em Questão de Horas
Publicado em: 12 de maio de 2005
Por Jeffrey R. Jones
Diretor, Unidade de Tecnologia e Negócios de Segurança da Microsoft
Veja outras colunas sobre Gerenciamento de Segurança.
Como parte do meu trabalho na Microsoft, eu passo boa parte do meu tempo analisando a segurança do sistema operacional, feedbacks dos clientes, métrica para progresso, e como estes três elementos se cruzam. Uma coisa que descobri é que existe um abismo entre a idéia teórica de segurança e as preocupações com a segurança prática que os clientes expressam. Este artigo é o terceiro de uma série de quatro artigos nos quais estarei examinando estas preocupações e levantando questões sobre o uso de sistemas operacionais baseados no Windows Microsoft ou no Linux.
No mês passado, estava lendo um artigo do Steven Suehring chamado "Uma Abordagem Que Funciona: Comparando a Segurança de Código Aberto e Fechado." O artigo inteiro era um pouco prolixo, mas este parágrafo chamou minha atenção:
O timing das atualizações de segurança é a melhor maneira de demonstrar a diferença entre como estes dois modelos abordam esta questão. Um dos aspectos da segurança no código aberto é a transparência - virtualmente assim que uma falha de segurança, teórica ou prática, é relatada, é divulgada publicamente para que os usuários do software possam tomar medidas para mitigar os efeitos da falha de segurança. Rapidamente, uma atualização é lançada para os pacotes mais usados de software de código aberto. Se uma atualização não estiver disponível em questões de horas, a comunidade freqüentemente toma a dianteira e lança uma atualização intermediária e ajuda os demais a mitigarem seus problemas associados com a falha.
Em primeiro lugar, devo concordar com Steven quando diz que as atualizações de segurança são capazes diferenciam de maneira interessante os dois modelos. No entanto, ele faz duas declarações importantes, uma implícita e outra explicita, e peço licença para examiná-las mais detalhadamente:
1. | "Rapidamente, uma atualização é lançada…" Não existem definições para "rapidamente", mas o contexto do artigo certamente implica que as atualizações são disponíveis mais rapidamente para o modelo de código aberto do que na Microsoft (código fechado). |
2. | "Se uma atualização não estiver disponível em questões de horas, a comunidade…" Em outras palavras, se as distribuições não forem rápidas o suficiente, a comunidade disponibilizará atualizações para você. |
Eu tenho uma natureza questionadora. As distribuições da Linux realmente produzem patches (atualizações) mais rapidamente? Tenho certeza de que você pode lembrar de um exemplo, mas, na média, em todas as atualizações? Se não, a comunidade então produz atualizações para mim? Quantas foram produzidas no ano passado? Onde eu as encontro? Elas podem quebrar meu sistema? Estas perguntas não são arbitrárias; são o tipo de pergunta que um administrador de atualizações pode perguntar independente das atualizações serem de um fornecedor ou de qualquer outra fonte.
As Atualizações Mais Rápidas para Vulnerabilidades Reveladas
Eu vou gastar um bom tempo na primeira declaração que implica que os sistemas da Linux fornecem atualizações mais rapidamente. Existem estudos sólidos que examinam isto detalhadamente e mostram que, apesar de muitos acreditarem justamente no contrário, o Microsoft Security Response Center (MSRC) fornece atualizações para os clientes para os problemas revelados publicamente em muito menos tempo que as principais distribuições da Linux.
Em Março de 2004, a Forrester lançou um estudo independente e sem financiamento (faça o download aqui) da Microsoft e de quatro das principais distribuições da Linux. As análises de todas as vulnerabilidades em um período de um ano concluíram que enquanto a Microsoft forneceu uma atualização em 25 dias em média, a distribuição da Linux que mais se aproximou disso, a Red Hat, levou em média 57 para produzir uma atualização. Note que cada fornecedor validou os dados também, como está indicado nos reconhecimentos:
A Forrester agradece a Noah Meyerhans da Debian, a Vincent Danen da MandrakeSoft, a Allen Jones da Microsoft, a Mark Cox da Red Hat, e a Roman Drahtmüller da SUSE pelo tempo que eles generosamente dedicaram a esta pesquisa.
Em Março de 2005, Security Innovation LLC fez uma pesquisa de follow-up (faça o download aqui) comparando o conjunto completo de componentes do Windows Server 2003 com um servidor da web LAMP usando o Red Hat Enterprise Linux 3 Advanced Server. Este estudo cobriu 2004 vulnerabilidades e concluiu, novamente, que a distribuição da Linux demorou o dobro do tempo, em média, para fornecer as atualizações para os seus produtos e componentes.
E a Comunidade "Atualizações em Questão de Horas"?
Das informações que consegui colher analisando fatos ocorridos, os problemas que recebem muita atenção da mídia ou cobertura da imprensa provavelmente resultarão em atualizações da comunidade que serão desenvolvidas e publicadas. Os problemas divulgados também tendem a ser aqueles que os fornecedores de distribuições da Linux corrigem mais rapidamente, portanto, o benefício das atualizações da comunidade pode ser questionável. Tendo isto em mente, vamos analisar algumas questões específicas.
Aqueles Que As Distribuições Atrasam ou Esquecem
Se uma distribuição Linux faz uma atualização de uma vulnerabilidade rapidamente, então uma atualização da comunidade não é necessária. E as vulnerabilidades que as distribuições demoram mais para atualizar?
Mark Cox da Red Hat publicou alguns dados sobre vulnerabilidades corrigidas no Red Hat Enterprise Linux 3 (rhel3as) em seu blog e os tornou disponível no http://people.redhat.com/mjc/. A partir destes dados, podemos identificar algumas vulnerabilidades que demoraram mais tempo para serem corrigidas, e que podiam ser exploradas remotamente e foram consideradas vulnerabilidades de alta gravidade pela ICAT (veja aqui para mais informações): CAN-2002-1363, CAN-2004-0409, CAN-2004-0836, e CAN-2004-0419 - o mínimo que estas 4 ficaram expostas foi 138 dias, quando a Red Hat lançou uma atualização.
A CAN-2002-1363 tornou-se pública em 2002 antes do rhel3as ser lançado, já que era uma atualização para o problema no libpng da Debian e em outros. Portanto, quando um rhel3as novo em folha é implantado, supomos que o problema já tenha sido corrigido, certo? Pesquisamos todos os problemas que foram divulgados antes do lançamento do rhel3as e checamos o código da fonte para garantir que tenham sido corrigidos? Uma atualização da comunidade estava disponível, mas como você poderia saber que precisaria dela?
CAN-2004-0409. Se você estava inscrito no mailing list de discussões do xchat no dia 4 de abril de 2004, deve ter recebido uma notificação dizendo que havia uma vulnerabilidade e que uma atualização da fonte estava disponível no site xchat.org. Caso contrário, você provavelmente ouviu falar sobre este problema ao monitorar o mailing list do Bugtraq e ver um consultivo da Debian no dia 21 de abril. Se você não estava inscrito em nenhum destes mailing lists, você teria recebido então um consultivo de segurança da Red Hat em outubro avisando-o sobre a atualização.
CAN-2004-0836. Este problema da mysql foi descoberto no dia 4 de junho. Se você participava do mailing list da mysql, você teria sido notificado sobre uma correção no código da fonte no dia 17 de junho. Caso contrário, você receberia um consultivo da Red Hat em outubro avisando-o sobre a atualização para este problema.
CAN-2004-0419. No dia 19 de maio, este problema foi revelado no banco de dados de erros de programação do XFree86 junto com uma correção que fora enviada. Parece que a correção era simples e estava comprometida com a arvore. Se você não acompanhasse atentamente o banco de dados de erros de programação do XFree86, você poderia descobrir este problema apenas quando recebesse um consultivo de um fornecedor, como o do Red Hat, em outubro.
Apesar destes quatro problemas serem de alta gravidade e poderem ser explorados remotamente, eu não consigo encontrar nenhuma informação sobre estes problemas quando eles foram descobertos, apenas quando foram corrigidos por uma das principais distribuições. Isto nos leva à próxima pergunta.
Como um Administrador Descobre Estes Problemas?
Nos exemplos examinados acima, mesmo que acompanhasse o Bugtraq, um administrador de TI não teria facilmente ficado ciente da vulnerabilidade do software antes que um dos principais fornecedores lançasse um consultivo. Portanto, mesmo que houvesse uma atualização da comunidade, para que serve esta atualização se um administrador não sabe onde encontrá-la e como aplicá-la?
Os hackers podem selecionar alguns componentes críticos e monitorar o bugzillla, mudanças na fonte e uma variedade de fontes até que encontrem uma vulnerabilidade que possam explorar. Parece que, teoricamente, é possível manter-se informado sobre a maioria dos problemas divulgados caso isto seja um hobby ou um trabalho em tempo integral, mas não deve ser prático para a maioria dos profissionais de TI que são responsáveis pela proteção de seus sistemas.
Ao invés disso, parece que a maioria das notificações para profissionais de TI vem de fontes como o Bugtraq, a SecurityFocus, ou de consultivos de fornecedores, e neste ponto a atualização da comunidade talvez nem seja mais necessária.
No entanto, vamos assumir que exista uma atualização da comunidade disponível antes da atualização do fornecedor e que um administrador saiba sobre ela e gostaria de implantá-la.
Como Devo Implantar uma Atualização para Todos os Servidores?
A maioria dos clientes empresariais da Linux possui o Red Hat ou o SUSE, portanto eles usarão o up2date ou o yast. O uso esperado destas ferramentas é buscar as atualizações aprovadas no site do fornecedor e implantá-las em seus computadores. No entanto, as ferramentas do pacote estão disponíveis para uso administrativo também. É possível:
| • | Aplicar a atualização da comunidade ao código apropriado e recompilar. |
| • | Montar um novo pacote de RPM a partir da fonte e colocá-lo em um depósito de atualizações local. |
| • | Usar as ferramentas de gerenciamento de atualização/RPM para expelir o pacote. |
Este parece ser um processo que você não gostaria de fazer para uma grande empresa freqüentemente, mas é possível de ser feito. Demonstrada a praticabilidade, existem ainda algumas questões que um administrador deveria considerar - a primeira delas seria testar.
Qualidade e Testes - Posso Confiar Nesta Fonte?
E se eu ignorar os testes e simplesmente rodar a atualização da comunidade? Mike Howard tem um ótimo exemplo dos riscos das atualizações da comunidade em seu blog nesta página. Em resumo, um estouro do buffer no Apache 1.3 foi descoberto no Bugtraq e uma atualização da comunidade foi rapidamente publicada para quem quisesse usá-la. Apesar da atualização ter corrigido o estouro do buffer, Mike percebeu que ela introduziu um novo estouro do buffer!
Para usar as atualizações da comunidade com segurança em ambientes de produção, parece que é preciso assumir a responsabilidade extra e os recursos para testes. Este "benefício" parece estar se transformando num incomodo para o típico administrador de sistemas. Se um administrador não possui os recursos ou o tempo para fazer os testes de compatibilidade e regressão que um empregador pode exigir, então é melhor esperar o lançamento da atualização do fornecedor.
Quem Suporta Minha Atualização da Comunidade?
As distribuições corporativas do Commercial Linux, como a Red Hat e o SUSE, tiram um snapshot de todos os componentes e então se comprometem a suportá-los por diversos anos. Os termos e condições da Red Hat certamente parecem permitir modificações da fonte para a maioria dos componentes.
No entanto, na prática, se você ramificar o código da fonte, quem será responsável por garantir que as suas mudanças permaneçam no código e não entrem em conflito com outras mudanças "oficiais" lançadas pelo fornecedor?
Vamos examinar um cenário utilizando a vulnerabilidade do kernel CAN-2004-1234. Este problema foi divulgado no dia 8 de abril de 2004, junto com uma alteração proposta para corrigi-lo. Digamos que um administrador no Red Hat Enterprise Linux 3 Advance Server deu uma olhada na mudança e decidiu ele mesmo aplicá-la. Ele faz o que tem que ser feito, recompilando kernels, distribuindo, e reiniciando. Ótimo, a atualização da comunidade ajudou a melhorar a segurança. Mas o que pode acontecer depois?
Entre 8 de abril e 23 de dezembro de 2004 (data na qual a Red Hat publicou uma correção para o CAN-2004-1234), a Red Hat publicou consultivos de segurança corrigindo 28 vulnerabilidades no kernel através de seu up2date e do mecanismo da Red Hat Network. Quando cada um destes consultivos foi lançado, o administrador enfrentou o seguinte dilema:
| • | Ele deve fazer o download da mais nova fonte do kernel da Red Hat e migrar sua atualização para ela e fazer o rollback de tudo aquilo manualmente? |
| • | Ele deve pegar a nova atualização binária do up2date e fazer o rollback de todo o trabalho que ele havia feito para corrigir o CAN-2004-1234? |
Existem muitos outros exemplos como este, mesmo que considerarmos só o kernel. É uma decisão difícil, mas pela viabilidade, acredito que a maioria dos administradores decidirá no futuro ficar com as atualizações "aprovadas pelo fornecedor" como o melhor negócio em se tratando de segurança e custo operacional.
E Se a Microsoft Lançasse Atualizações Não Testadas?
A outra maneira de examinar os benefícios das "atualizações em questão de horas" é imaginar a Microsoft fazendo o mesmo. Um desenvolvedor termina sua atualização proposta. Assim que a atualização vai para a equipe de teste, a MSRC também a publica para que os clientes a utilizem por conta própria e risco próprio, junto com um boletim de segurança avisando que ainda não foram feitos testes de compatibilidade ou regressão.
Na teoria, é completamente viável para a Microsoft, se quase todos os clientes realmente querem isto e estão dispostos a correr este risco. Lembre-se de que boletins de segurança com atualização tornariam o problema público, portanto todos iriam torcer para que a atualização não testada realmente funcionasse.
Parece que este é um processo que muitos clientes estão aguardando ansiosamente? Pela minha experiência, este é o oposto do que os clientes desejam.
Conclusões
Quando comparamos fornecedores ou produtos, freqüentemente os valores e benefícios são simplificados e resumidos em frases como "atualizações em questão de horas". Para qualquer um oferecendo um produto para empresas, junto com suporte e comprometimento com o ciclo de vida, fornecer correções de segurança é um requisito básico.
No entanto, se formos além do que é básico, existem implicações práticas para o risco de segurança que surge a partir dos requisitos de empresas que possuem correções de software que podem ser implantadas em ambiente de produção. Quando o modelo de código aberto é considerado em termos da disponibilidade das "atualizações da comunidade" cruzando com a das atualizações aprovadas do fornecedor e dos mecanismos de distribuição, a situação apresenta desafios reais e escolhas difíceis de serem tomadas no gerenciamento de riscos de segurança.
Como em qualquer discussão comparativa como esta, aconselho uma reflexão sobre a questão e que você possa então tirar suas próprias conclusões. Foram fornecidas diversas referencias que podem ser lidas e listei algumas questões que talvez você queira discutir com o seu fornecedor.
Acompanhe o próximo artigo, no mês que vem, desta série sobre questões práticas de segurança a serem consideradas em ambientes operacionais.
Atenciosamente,
Jeffrey R. Jones
Diretor Sênior, Unidade de Tecnologia e Negócios de Segurança da Microsoft