Conteúdo: Política de Segurança Pacotes e repositórios Avisos de atualização Atualizações anteriores Reportando problemas de segurança Motivação Procedimento O relatório Pacotes e repositórios * Pacotes RPM: Todos os pacotes RPM liberados pela Conectiva, seja na forma da própria distribuição, ou na forma de atualizações, são assinados com a chave GPG. Esta chave está no CD e no pacote gnupg. Para checar um pacote RPM, faça: [user@host user]$ rpm -v -K bash1-1.14.7-31cl.i386.rpm bash1-1.14.7-31cl.i386.rpm: MD5 sum OK: 8341a18e5d16f8242440bc4908d249b9 gpg: Assinatura feita em qui 30 nov 2000 15:17:27 EST usando DSA, ID da chave 9 9807190 gpg: Assinatura correta de "Conectiva S.A. " Nota: sem a opção "-v" não há como saber de quem é a assinatura. O que isto quer dizer? Quer dizer que a Conectiva empacotou o programa e assinou o pacote. Se o pacote for eventualmente adulterado, a assinatura não baterá mais e o RPM irá mostrar isso. O md5 até pode ser regerado pelo atacante, mas não a assinatura. Note que o MD5SUM reportado pelo RPM é diferente do MD5SUM reportado quando se roda md5sum no arquivo RPM, isto é normal. * Repositório APT: Todos os repositórios oficiais da Conectiva são assinados com a chave GPG. Por padrão, o apt irá checar a assinatura do repositório. Que tipo de falhas ele vai detectar? + Arquivos adulterados: o repositório assinado contém o md5sum dos arquivos de índice, que por sua vez contém o md5sum de todos os pacotes. + Repositórios adicionais: se forem pedidos repositórios adicionais que não estiverem no arquivo assinado, o apt irá parar e emitir um aviso. Isso evita que, por exemplo, um site faça mirror do repositório oficial e acrescente um repositório próprio junto com o oficial. Também não deixa que o usuário acrescente um componente no arquivo de configuração local que não exista no repositório assinado do site. Instruções de como usar assinaturas GPG junto com o apt podem ser encontradas nos manuais do Conectiva Linux. Avisos de atualização Todos os anúncios de atualizações do Conectiva Linux enviados por email são assinados com a chave GPG e numerados. Se um anúncio for falsificado ou adulterado, a assinatura não será mais válida. A maioria dos clientes de email pode ser configurada para usar GPG e checar automaticamente a assinatura digital de emails assinados. Infelizmente, algumas listas que recebem os nossos anúncios algumas vezes reformatam o texto para um número específico de colunas. Com isso, o email fica modificado e a checagem da assinatura irá falhar. Por isso, é recomendado que os usuários do Conectiva Linux assinem diretamente a lista de atualizações. Veja como em http://distro.conectiva.com.br/lista/#anuncios. Atualizações anteriores Quando um mesmo pacote sofre mais de uma atualização, os arquivos das atualizações anteriores são removidos do ftp. O anúncio anterior, no entanto, permanece. Atualmente o site de atualizações não agrupa as atualizações de um mesmo pacote, por isso, se houver um erro de arquivo não encontrado ao seguir um link contido em um anúncio, é provável que exista outra atualização mais recente para este pacote. Além disso, a página de atualizações lista que versões da distribuição ainda são mantidas. Versões mais antigas da distribuição ainda permanecem no ftp, não são mais mantidas. Reportando problemas de segurança Motivação Há basicamente três formas de se lidar com relatórios de falhas de segurança, cada uma com vantagens e desvantagens: * publicar o problema imediatamente, sem avisos * avisar o autor/distribuidor e aguardar a solução * avisar o autor/distribuidor e aguardar, mas soltar o aviso se demorar muito A questão toda é: qual a forma menos danosa para os usuários? Sim, danosa, pois um problema de segurança sempre é negativo. Então, qual a melhor forma de abordar a vulnerabilidade e como conduzir a sua correção? A forma preferida nos meios de Segurança é a terceira, por diversos motivos: * Permite que o autor/distribuidor faça uma atualização oficial. Normalmente, o autor do programa é quem o conhece melhor e está em melhor posição para corrigir o problema. No caso do distribuidor, ele está em melhor posição para notificar seus usuários do problema e como corrigi-lo, ou seja, como fazer a atualização. * Se o autor/distribuidor não se manifestar, ou demorar muito e não tiver um bom motivo para essa demora, a vulnerabilidade é simplesmente tornada pública. Funciona tanto como pressão para que uma solução seja logo encontrada como também serve para avisar os usuários da existência do problema, dando a eles uma chance de tomar alguma medida. É possível que nem todos os usuários tenham conhecimentos técnicos suficientes para conseguir contornar o problema, mas pelo menos assim se estará protegendo uma parcela dos usuários. * Nem todos os usuários assinam listas específicas de segurança, mas boa parte deles assina alguma lista de avisos de atualização do distribuidor. Normalmente a vulnerabilidade, quando liberada publicamente antes de qualquer aviso ao distribuidor/autor, somente é publicada em fóruns específicos de segurança, deixando muitos usuários ainda desprotegidos. Acreditamos ser esta a forma mais flexível de se lidar com problemas de segurança e a menos danosa para os usuários da distribuição, pois dá uma chance para se obter uma solução oficial e, caso esta não seja satisfatória ou demore muito, a vulnerabilidade pode ser publicada assim mesmo de forma a permitir que os usuários tomem suas próprias medidas. Um excelente documento sobre este assunto pode ser encontrado em http://www.wiretrip.net/rfp/policy.html feito por Rain Forest Puppy contando com a colaboração de centenas de usuários: Full Disclosure Policy (RFPolicy). Procedimento Se você acredita ter encontrado um problema de segurança em algum pacote ou programa enviado com alguma versão da distribuição Conectiva Linux, nós o encorajamos a enviar um relatório para nós. Há basicamente duas formas de se fazer isso: * Bugzilla: neste caso, o problema de segurança será tornado público imediatamente, pois o Bugzilla é um fórum público. O bug terá um número e todos poderão acompanhar o desenrolar da solução. Alguns usuários já poderão imediatamente tomar providências para se proteger, mas outros talvez não tenham conhecimento técnico suficiente para fazer isso e poderão se tornar vítimas, já que a vulnerabilidade foi publicada. * De forma privada: usando o endereço de email security@conectiva.com.br e criptografando a mensagem com a chave pública da Conectiva, apenas o time de segurança da Conectiva receberá esta informação. O remetente também deve possuir uma chave pública e deve assinar o email com sua chave privada de forma que seja possível criar um canal de comunicação seguro. Nós o encorajamos a utilizar a alternativa do email criptografado por acreditarmos esta ser a menos danosa para os usuários a curto prazo. Todos os relatórios serão analisados e respondidos. Todos os créditos devidos serão dados quando do anúncio da vulnerabilidade e da solução oficial. O relatório Aqui apresentamos uma sugestão de que itens deveriam constar em um aviso de segurança de algum programa/pacote no Conectiva Linux. Isso não quer dizer que avisos fora desse modelo não serão considerados, muito pelo contrário. O descobridor da vulnerabilidade é livre para fazer o que bem entender com essa informação. Isto é apenas uma sugestão para que o problema seja rapidamente localizado e solucionado. Quanto mais informações forem fornecidas, melhor será. O descobridor da vulnerabilidade deve procurar fornecer a maior quantidade possível de informações sobre o problema: * Demonstração: um script, um programa em C, uma linha de comando, etc. O que for necessário para demonstrar a vulnerabilidade; * Versão utilizada: é muito importante especificar em qual versão do programa/pacote o problema ocorre, e também se alguma versão está imune à vulnerabilidade. Uma outra versão pode não apresentar o mesmo problema por não possuir uma certa característica, ou por ter sido compilada com alguma outra biblioteca, ou por uma situação diferente de arquivos de configuração default, etc. * Trechos de código: se for um programa de código aberto, onde o problema ocorre. Isto também pode ser usado na parte de demonstração da vulnerabilidade. * Cenários: às vezes, uma vulnerabilidade pode não ser vista imediatamente como um problema de segurança, mas simplesmente como mais um bug de software. Neste caso, é muito importante mostrar um cenário onde isso poderia constituir um problema de segurança. * Possíveis soluções: se existirem formas de contornar a vulnerabilidade até que seja lançada uma atualização oficial, ou sugestões de patches, mudanças em opções de configuração, etc.