Gerenciamento da Segurança - Abril de 2005
Segurança em Operações (2/4): Quando um Problema Afeta Diversos Produtos
Publicado em: 6 de abril de 2005
Por Jeffrey R. Jones
Diretor, Unidade de Tecnologia e Assuntos de Segurança da Microsoft
Veja outras Colunas sobre Gerenciamento da Segurança.
Como parte do meu trabalho na Microsoft, eu passo boa parte do meu tempo analisando a segurança OS, feedback 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 segundo 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.
Não é de todo incomum que qualquer vulnerabilidade encontrada afetará diversos produtos ou versões de um produto. Apesar deste ser um fato óbvio, gostaria de aprofundá-lo para expor como a Microsoft e como a comunidade Linux/Open Source (de Código Aberto) lidam com a questão, e para examinar algumas das implicações práticas para os clientes.
Lista Mitre CVE
As pessoas que começam a aprender sobre vulnerabilidades de software rapidamente ficam sabendo que o ID do Mitre Common Vulnerabilities and Exposures (CVE) (leia a respeito aqui) é identificador padrão usado. Pode-se pegar um exemplo de identificador, CAN-2004-1234 e checar no Mitre escrevendo antes do ID "http://cve.mitre.org/cgi-bin/cvename.cgi?name=" para criar uma URL (por exemplo, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1234).
Examinando o exemplo "1234" que escolhi, nós vemos que existem referências ao Red Hat Security Advisory, uma referência ao BitKeeper, uma indicador para o Bugzilla, o Securityfocus, e o ISS. A página de referência do Securityfocus indica que todos os kernels do Linux anteriores a 2.4.26 são afetados e lista mais de 100 versões de distribuições do Linux que incorporam estas versões kernel e são negativamente afetados.
Implicações de Risco de Segurança em Diversas Versões Vulneráveis
Voltando a usar a Microsoft como exemplo, vamos examinar o Boletim de Segurança MS04-018. Este boletim avisa os clientes sobre um problema de verificação no cabeçalho que afeta o Outlook Express (OE) e poderia permitir que um hacker fizesse um estrago no OE. O boletim indica que seis versões suportadas atualmente pelo OE são afetadas quando executadas em diversas versões do sistema operacional Windows, desde Windows 98 e Windows NT.
E se a Microsoft tivesse lançado primeiro uma correção apenas para a versão do OE executada no Windows XP, com a intenção de lançar correções para as outras versões depois de algum tempo? Como isto afetaria o risco de segurança nas demais versões? Existem duas situações:
| • | Se o problema já é de conhecimento público, o a lançamento da correção destaca ainda mais a vulnerabilidade e a torna ainda mais conhecida para um número ainda maior de pessoas. |
| • | Se o problema ainda não é de conhecimento público, o lançamento o torna público e conhecido para um número ainda maior de pessoas. |
Em ambas situações, o risco de segurança apenas aumentaria para os usuários das versões cuja correção ainda não está disponível pois um número maior de hackers em potencial ficaria sabendo sobre o buraco, e os fornecedores não poderiam ainda oferecer uma correção aos seus consumidores. Isto leva a conclusão de que para minimizar o risco de segurança para os clientes de todas as versões de um produto, um fornecedor deve ter uma política de lançamento simultâneo de correções para todas as versões.
Problemas que Afetam Diversos Produtos da Microsoft
Quando a Equipe de Resposta de Segurança da Microsoft (Security Response Team) fica ciente, de maneira pública ou privada, de uma vulnerabilidade da segurança, a Microsoft tem uma política de corrigir todas as versões suportadas, em todas os idiomas, ao mesmo tempo. Esta política é possível porque a Microsoft fornece suporte e manutenção para todas as versões afetadas. Em um artigo que escrevi no ano passado, abordei detalhadamente como a Microsoft lida com problemas que são relatados.
O custo principal do processo de correção de todas as versões suportadas ao mesmo tempo é que qualquer problema encontrado durante os testes em uma das correções causará um atraso no lançamento de todas as correções. Como praticante de medidas de segurança, encaro este custo como gasto que vale a pena em troca da redução do risco de segurança para todos os usuários das diversas versões do produto.
Questões que Afetam Diversos Produtos de Código Aberto/Linux
Tanto a vantagem quanto a desvantagem do software de código aberto é que qualquer um pode criar uma variante e começar a suportá-la. Em relação ao tópico deste artigo, no entanto, o desenvolvimento do modelo de código aberto traz alguns desafios extras em termos de segurança.
Recapitulando nosso exemplo "1234" que afetou mais de 100 distribuições do Linux: É possível coordenar o lançamento de uma única correção para todas as versões ao mesmo tempo? Teoricamente, com certeza! Na prática, é um pouco mais difícil. Existem pelo menos duas partes do modelo de código aberto que apresentam desafios nesta área:
| • | Problemas corrigidos primeiro por uma das diversas distribuições do Linux (por exemplo, Gentoo, Debian, ou Red Hat). |
| • | Problemas encontrados e corrigidos por uma das equipes de desenvolvimento de componentes (por exemplo, Mozilla ou gcc) |
O Problema da Distribuição Múltipla
O site distrowatch afirma:
Uma distribuição do Linux é como se fosse uma religião. Se você já tentou alguma vez sugerir para alguém que uma escolha de distribuição talvez não tenha sido a melhor, então você sabe do que estou falando. Mesmo se não tenha passado por isso, você certamente já viu uma "guerra de opinião sobre distribuição" em uma das listas de mailing ou fóruns de discussões. Tudo bem. Devemos defender as coisas que gostamos, mesmo que seja apenas um código de programação. O quem vem a seguir são fatos e números sobre as distribuições Linux. As opiniões pessoais podem variar, mas é um pouco mais difícil discutir os fatos...
O site continua dizendo que:
Atualmente, existe um total de 386 distribuições da Linux e 9 distribuições BSD no banco de dados. Destas distribuições, 50 foram oficialmente descontinuadas, ou o website da distribuição (ou informações do produto) simplesmente desapareceu ou tornou-se inativo (isto é, não foi lançada uma nova versão a pelo menos dois anos e seus sites não dão nenhuma indicação de que estejam trabalhando para isso).
Vamos dar uma olhada no nosso exemplo 1234 novamente e ver o que aconteceu.
| • | No dia 9 de abril de 2004, Kirill Korotaev enviou uma mensagem para a lista de mailing do kernel do linux, a qual foi respondida por Chris Wright da OSDL, dizendo sim e que a correção já está no kernel 2.6. |
| • | A Red Hat lançou uma correção com o Consultivo de Segurança (Security Advisory) RHSA-2004:689 no dia 23 de dezembro de 2004. A Red Hat reconheceu que Kirill Korotaev havia descoberto o problema. |
| • | De acordo com a ISS e com a Securityfocus, dia 23 de dezembro foi o primeiro dia da revelação em público do problema CAN-2004-1234 para qualquer um fora da lista de assinantes do kernel do linux. |
| • | A Avaya, que usava o Red Hat em alguns de seus produtos, editou o consultivo ASA-2005-006 no dia 12 de janeiro, avisando da correção. |
| • | Para as distribuições da Fedora, a Fedora Core lançou o FLSA:2336 no dia 24 de Fevereiro de 2005, dois meses após o consultivo de segurança da Red Hat. |
| • | Até agora, não consegui encontrar consultivos em qualquer uma das demais distribuições. Por exemplo, apesar da SuSE Enterprise Linux 8 estar listada como afetada, a Novell ainda não lançou um consultivo de segurança que menciona o CAN-2004-1234. |
Este exemplo enfatiza que quando uma distribuição avisa sobre uma correção de segurança, outras distribuições podem correr um risco alto até que elas próprias lancem a correção.
Note que uma vantagem para os usuários de uma destas distribuições desatualizadas e desavisadas é que eles podem obter uma correção do kernel diretamente e aplicá-la - mesmo que seu fornecedor ainda não os tenha notificado sobre o problema de segurança ou editado uma correção. Poderia haver implicações em seus acordos de suporte, mas existe esta opção.
O Problema do Componente Atualizado (Patched)
As distribuições do Linux são criadas ao tirar um snapshot de diversos componentes em determinado momento e, com uma cola de desenvolvimento de distribuição, lançar o conjunto como uma versão OS. Exemplos disto seria o Red Hat Enterprise Linux AS v2.1, o SuSE Linux Enterprise 8, e o Ubuntu 4.10. Vamos dar uma olhada no SUSE Security Announcement - kernel (SUSE-SA:2004:037) que era direcionado para o CAN-2004-0816 no SuSE Linux Enterprise Server 9 (SLES9) em 20 de outubro de 2004. O consultivo diz:
Um problema de underflow de um número inteiro nas regras de registro do firewall iptables pode permitir que um agressor remoto invada a máquina usando um pacote de IP artesanal. Este ataque só seria possível com o sistema de firewall habilitado.
Nós gostaríamos de agradecer Richard Hart por ter relatado o problema.
Este problema já foi corrigido no upstream 2.6.8 do kernel do Linux, esta atualização contém um backport da correção.
O uso da expressão "backport" indica que o novo componente tem problemas de distribuição. Informações no Securityfocus mostram que qualquer distribuição utilizando a versão 2.6 do kernel anterior ao 2.6.8 está afetada. A equipe deles de kernel trabalhou no problema - a correção serve para atualizar o kernel para a 2.6.8 ou versão posterior.
O problema é que algumas distribuições tiraram um snapshot do kernel anterior ao 2.6.8, e aquela versão é a que os seus clientes utilizam como a versão suportada. O SuSE SLES9 eu mais algumas versões do MandrakeSoft estão nesta categoria. Portanto os fornecedores devem fazer o backport da correção e lançá-la como uma atualização para a versão do kernel que eles se comprometeram a suportar para seus clientes, como a SuSE o fez. Note que o problema de distribuição múltipla aparece aqui também, já que os usuários do MandrakeSoft só receberam uma atualização no dia 25 de janeiro de, 2005, com o MDKSA-2005:022.
Dando um segundo exemplo, de outro ponto de vista, observando os problemas que afetaram o v1.3 no web site do Apache, encontramos o CAN-2004-0174. A primeira referência para o CVE é de um anúncio no bugtraq em 19 de março de 2004, que o Apache HTTP Server 2.0.49 lançou. O aviso destaca que o 2.0.49 corrige o CAN-2004-0174 desde a 2.0.48. Checagens subseqüentes mostram que várias distribuições ofereceram consultivos de segurança para suas versões do Apache para seus clientes:
| • | 30 de março de 2004, Trustix |
| • | 3 de maio de 2004, Apple |
| • | 12 de maio de 2004, OpenPKG e Slackware |
| • | 17 de maio de 2004, MandrakeSoft |
| • | 26 de maio de 2004, Gentoo |
| • | 23 de julho de 2004, Red Hat |
Um exemplo final vem da Debian Security Advisory DSA-639, que explicitamente informa as 10 seguintes vulnerabilidades:
Andrew V. Samoilov notou que diversos corretores que eram aplicados à fonte por desenvolvedores de cima (upstream) do mc, o midnight commander, um navegador e gerenciador de arquivos, não estavam sendo backport para a versão atual do mc que a Debian inclui em seu lançamento permanente.
Portanto, apesar do modelo de código aberto permitir que cada um destes fornecedores faça ajustes em suas próprias versões de um componente e, potencialmente, se comprometam a suportar clientes muito além do que a equipe de componentes já faz, existem alguns problemas práticos envolvendo a manutenção da segurança que acabam afetando e arriscando tais clientes.
Conclusões
Ao comparar fornecedores ou produtos, freqüentemente os valores e benefícios são simplificados e comparados também de maneira simplista. Para qualquer um que ofereça um produto para empresas, junto com suporte e comprometimento do ciclo de vida, o fornecimento de correções de segurança é um requisito básico.
No entanto, quando vamos além do básico, existem as implicações práticas dos riscos de segurança advindos tanto das políticas do fornecedor quanto de sua habilidade para suportar versões múltiplas de maneira pontual. Quando o modelo de código aberto é considerado sob esta ótica, múltiplos fornecedores e múltiplos distribuidores têm uma relação de dependência e sofrem impactos óbvio um sobre o outro, e isso representa um verdadeiro desafio para o gerenciamento dos 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, embora tenha certeza que você fará também suas próprias perguntas.
Acompanhe o próximo artigo, no próximo mês, nesta série sobre questões práticas de segurança a serem consideradas em ambientes operacionais. Irei explorar algumas das considerações práticas sobre segurança relacionadas às "correções disponíveis em algumas horas."
Atenciosamente,
Jeffrey R. Jones
Diretor Sênior, Unidade de Tecnologia e Negócios de Segurança da Microsoft