Debian, OpenSSL e a falta de cooperação

Debian, OpenSSL, and a lack of cooperation

Autor original: Jake Edge

Publicado originalmente no: https://lwn.net/

Tradução: Roberto Bechtlufft

Uma falha de segurança horrenda no pacote OpenSSL do Debian gerou muito interesse – e bastante controvérsia – entre os usuários do Linux. O bug está circulando há dois anos no Debian e em outras distribuições baseadas nele, como o Ubuntu. O problema mostra que há muitas lições a serem aprendidas sobre o trabalho em equipe de distribuições e projetos ou, neste caso, sobre o fracasso desse trabalho colaborativo.

Em abril de 2006, um usuário do Debian relatou um problema no uso da biblioteca OpenSSL com o valgrind, uma ferramenta que busca problemas de acesso à memória em programas. Segundo ele, o OpenSSL estava usando memória não-inicializada em partes do código do RNG, o gerador de números aleatórios. Usar memória antes que ela seja inicializada com um valor conhecido é uma maneira bem conhecida de de criar bugs difíceis de serem encontrados, por tanto não é de se surpreender que o relatório do valgrind tenha causado bastante preocupação.

Kurt Roeckx, hacker do Debian, rastreou o problema até chegar ao que ele pensou serem duas linhas de código problemáticas e postou uma pergunta na lista de discussão openssl-dev:

Na minha opinião, a melhor opção parece ser comentar essas duas linhas de código. Mas não faço idéia do efeito que isso terá no RNG. Acho que o único efeito será uma diminuição da entropia na fonte. Mas por outro lado, não estou certo da quantidade de entropia que dados não-inicializados possuem.

O que vocês acham de remover essas duas linhas de código?

As respostas foram poucas, mas ninguém se opôs à remoção das linhas, incluindo Ulf Möeller que, usando um email openssl.org, respondeu: “se vai ajudar na depuração, sou favorável a remover as linhas.” Infelizmente, como foi descoberto há poucos dias, remover umas das linhas era inofensivo, mas remover a outra arruinou o RNG, o que fez com que o OpenSSL passasse a gerar chaves criptografadas fáceis de se adivinhar (para mais detalhes técnicos sobre o bug e sobre como reagir a ele, consulte nosso artigo nas páginas de segurança).

Pelo visto, de acordo com Ben Laurie, membro do núcleo do OpenSSL, o desenvolvimento do OpenSSL não deve ser discutido na openssl-dev . Isso pode ser verdade na prática, mas a página de suporte descreve a lista desta forma: “Discussões sobre o desenvolvimento da biblioteca OpenSSL. Não poste perguntas sobre o desenvolvimento do aplicativo!” Além disso, o endereço sugerido por Laurie (openssl-team-em-openssl.org) não está na documentação online do OpenSSL. Ainda que a lista não fosse o lugar certo, os desenvolvedores do OpenSSL poderiam ao menos ter indicado o endereço correto, mas isso não aconteceu.

É provável que não tenha ficado claro que Roeckx representava oficialmente o Debian, nem que ele pretendia alterar o pacote do Debian baseado nas respostas que suas perguntas tivessem. Como Laurie corretamente aponta, ele deveria ter submetido um patch, propondo que este fosse aceito na base de código upstream do OpenSSL. Isso atrairia bem mais atenção, mesmo se o patch fosse postado apenas na openssl-dev. Seria muito improvável que o patch fosse aplicado a um lançamento oficial do OpenSSL.

É do interesse de todos, incluindo as distribuições, os projetos e os usuários, que as mudanças feitas localmente rumem ao upstream, ou seja, ao código base oficial do projeto. Para que isso aconteça, deve haver um compromisso das entidades locais – tipicamente as distribuições, mas por vezes os usuários – de levarem suas mudanças ao upstream. Da mesma forma, os projetos devem encorajar esse tipo de atividade ajudando os proponentes de patches ao longo do processo. Antes de mais nada, obviamente, deve ficar bem claro quais são os canais de comunicação adequados.

Outra vulnerabilidade recente também surgiu devido à falta de cooperação entre o projeto e as distribuições. É vital, especialmente para os pacotes de segurança centrais do sistema, como o OpenSSH e o OpenSSL, que as entidades locais e o upstream trabalhem juntos. Quaisquer mudanças nesses pacotes devem passar pela análise cuidadosa da equipe do projeto antes de serem incluídas em pacotes de uma distribuição. Uma coisa é deixar que um patch mal avaliado seja aplicado a um jogo ou a algum aplicativo de escritório que muitas pessoas usem, mas o SSH e o SSL formam a base de muitas das ferramentas usadas para proteger o sistema de ataques, e por isso precisam ter um padrão de qualidade maior.

Outra observação de Laurie, que também reforça a idéia da necessidade de um padrão de qualidade mais alto, é a falta de sincronismo entre o check-in a um repositório público e o alerta de segurança. Atacantes à espreita poderiam ter se aproveitado dos cinco ou seis dias que tiveram de vantagem, se tivessem monitorado o repositório e explorado a vulnerabilidade. Embora seja possível que alguém mal-intencionado já soubesse da falha, ainda que não tenham sido anunciados ataques, alertar a atacantes em potencial sobre esse tipo de falha bem antes de alertar aos usuários vulneráveis é um protocolo de segurança incrivelmente ruim.

Esse é o tipo de problema que poderia ter sido resolvido rápida e silenciosamente. Todas as distribuições afetadas – embora seja difícil listar todas as distribuições derivadas do Debian por aí – poderiam ter sido contatadas, para que o alerta de segurança e as atualizações dos pacotes afetados fossem coordenados. Qualquer dia desses, um problemas como esse ainda vai dar má fama ao Linux, a não ser que a comunidade possa coordenar melhor seu trabalho em equipe.

Créditos a Jake Edge – https://lwn.net/

Tradução por Roberto Bechtlufft <robertobech at gmail.com>