Resumo

  • A atualização do OpenSSL publicada pelo Debian em maio de 2008 corrigiu uma alteração específica do pacote que tornara previsível a geração aleatória. Ela protegeu novas chaves, mas não alterou chaves SSH, OpenVPN, DNSSEC e X.509 produzidas desde setembro de 2006 e levadas para outros sistemas.
  • O reparo só se completava ao ligar ações de vários proprietários: identificar a origem da credencial, bloquear famílias reconhecidas, gerar uma substituta com entropia correta, autenticar sua distribuição, remover a autorização antiga ou revogar o certificado e provar a rejeição no lado de cada dependente relevante.

A atualização acabou antes da autoridade

Uma chave criptográfica não carrega um recibo legível de sua entropia. Esse fato tornou o CVE-2008-0166 especialmente traiçoeiro.

Depois da instalação do pacote corrigido, o próximo pedido ao gerador do OpenSSL seguiria um caminho seguro. Uma chave privada criada na véspera não se recompunha. Um certificado não perdia a assinatura do emissor. Uma linha em authorized_keys não desaparecia de um servidor remoto. A atualização operava sobre código futuro; a autoridade da chave existia em estados históricos espalhados por outras máquinas.

A DSA-1571-1, de 13 de maio de 2008, por isso recomendou recriar todo material criptográfico gerado pelas versões afetadas a partir de 0.9.8c-1. O alerta para DSA foi ainda mais amplo: uma chave originalmente forte podia se tornar comprometida ao ser usada num sistema afetado, porque a assinatura dependia de um valor secreto aleatório.

O Ubuntu registrou a fronteira que o inventário precisava seguir. Sistemas baseados em Debian estavam diretamente expostos. Sistemas de outras famílias podiam ser afetados indiretamente ao importar chaves fracas. O pacote defeituoso tinha um local de origem; a credencial tinha mobilidade.

Como uma chave grande passou a vir de um catálogo pequeno

O bug Debian #363516 nasceu em abril de 2006 como uma discussão sobre alertas do Valgrind no gerador do OpenSSL. A leitura de memória não inicializada contaminava diagnósticos. O histórico posterior esclareceu que a mudança vulnerável efetivamente compilada apareceu em 0.9.8c-1, quando o md_rand.c modificado foi colocado no caminho usado pela construção.

A documentação SSLkeys do Debian resume o efeito. O gerador quebrado passou a depender, na prática, do identificador de processo. Havia 32.767 fluxos possíveis em cada uma de três classes de arquitetura, 98.301 no modelo descrito. Para tipos e tamanhos comuns, era possível pré-calcular candidatos e descobrir qual chave privada correspondia a uma chave pública observada.

Esse total não representa todas as chaves, nem quantifica invasões. Aplicações chamavam a biblioteca de formas diferentes; algoritmos, tamanhos e arquiteturas variavam; as listas não cobriam tudo. O número demonstra uma mudança econômica: a parte pública, que deveria ser segura para divulgação porque a metade privada era inalcançável, passou a funcionar como índice para um conjunto enumerável.

A chave podia conservar formato, assinatura e prazo. O que perdera era a exclusividade material do segredo.

O próprio Debian fechou a porta separadamente

Minutos depois da divulgação, o projeto Debian desativou autenticação SSH por chave pública em sua infraestrutura. Transferências, reconstruções e serviços automatizados dependentes de chaves precisavam provar que usavam material seguro ou substituir suas credenciais.

Essa intervenção local é decisiva. Se o patch tivesse revogado as chaves, bloquear os logins seria redundante. O projeto corrigiu a origem e, em seguida, exerceu seu próprio poder de dependente para parar de aceitar o passado.

No dia seguinte, a DSA-1576-1 introduziu openssh-blacklist e ssh-vulnkey. O servidor atualizado podia recusar chaves de usuário conhecidas como fracas, quando detectáveis. Chaves de host podiam ser regeneradas com confirmação administrativa. Ainda assim, cada direção de confiança exigia uma operação distinta.

Quando o servidor trocava sua chave de host, o cliente exibia o alerta de que a identidade remota havia mudado. Era exatamente o comportamento correto tanto diante de uma troca legítima quanto diante de um interceptador. A nova impressão digital precisava chegar por um canal confiável; desligar o alerta em massa eliminaria a recusa local que o SSH pretendia preservar.

Já uma chave de usuário nova precisava ser inserida em cada servidor, e a linha antiga removida de cada authorized_keys. Apenas adicionar a substituta mantinha duas entradas, uma delas ainda adivinhável. Continuidade e revogação eram decisões diferentes.

A lista negra dizia “não” somente ao que conhecia

O espaço reduzido permitiu uma defesa peculiar: enumerar chaves públicas fracas e distribuí-las para comparação local. Um aplicativo receptor podia negar uma credencial conhecida sem possuir a parte privada. A evidência publicada virava uma regra executável.

Mas o alcance permaneceu explícito. Debian falava em rejeição “quando possível”. O resultado Unknown (no blacklist information) de ssh-vulnkey não era aprovação. Significava que aquela versão do corpus não oferecia resposta. Sem procedência confiável, a orientação era gerar outra chave.

A DSA-1576-2 mostrou o risco de confundir ferramenta com oráculo. Entradas de authorized_keys iniciadas por opções — comando forçado ou restrição de encaminhamento, por exemplo — podiam ser ignoradas pelo primeiro parser. Uma chave comprometida continuava ativa, mas não aparecia no relatório. Atualizações posteriores do Ubuntu ampliaram formatos, módulos e tamanhos RSA, inclusive a verificação de certificados e pedidos de assinatura.

Essas revisões não anulam o controle. A lista impedia chaves cobertas num host nunca vulnerável e podia barrar seu reingresso futuro. Apenas obrigavam a declarar a precisão correta: correspondência prova que a chave pertence ao conjunto conhecido; ausência de correspondência não prova geração segura.

A mesma causa exigiu vários protocolos de retirada

O CERT listou SSH, OpenVPN, DNSSEC e X.509. Não existia uma revogação universal entre eles.

No SSH de usuário, a autoridade residia no arquivo remoto. A evidência de encerramento era a falha da chave antiga em cada servidor importante. Na identidade SSH do servidor, a confiança residia nos clientes e no modo como a nova impressão digital era autenticada.

No OpenVPN com segredo compartilhado, todos os pares precisavam trocar material em coordenação. Em VPN com certificados, havia também emissão, distribuição e rejeição do certificado anterior. A USN-612-3 alertou que chaves geradas para outros sistemas deveriam ser encontradas e substituídas no destino.

Em X.509, criar uma nova chave e reemitir um certificado não apagava o anterior. O emissor podia publicar a revogação; o serviço precisava instalar a nova cadeia; o cliente precisava obter estado recente. O RFC 5280 define o processamento de certificados e CRLs, mas não faz todo cliente instalado consultar a informação na mesma hora.

Em DNSSEC, uma chave podia alcançar delegações assinadas e caches. Em automação, podia sobreviver em imagens, cópias, equipamentos e parceiros. O arquivo removido do host gerador não tocava nenhuma dessas decisões.

O objeto de reparo era, portanto, a linhagem da credencial: geração, cópias, certificados, autorizações e todos os pontos onde ela recebia um “sim”.

Uma prova válida deixou de provar exclusividade

O SSH verifica que o participante conhece o segredo correspondente à chave pública. Não verifica se apenas a pessoa legitimamente autorizada conhece esse segredo. Um atacante que reconstruísse a chave privada fraca podia entregar uma prova matematicamente correta.

A validade sobreviveu à legitimidade.

As notas públicas de Heng Lu sobre primazia do código em execução ajudam a interpretar a mecânica, sem servir como fonte histórica. Boletim, patch, lista negra e status de certificado são informação e instrução. A recusa ganha efeito quando o servidor SSH, o par VPN ou o cliente PKI executa a regra. O Debian controlava seus pacotes e suas máquinas, não todos os arquivos de autorização para onde uma chave havia viajado.

Da mesma maneira, um sistema operacional nunca vulnerável não ficava fora do incidente se sua configuração aceitava uma chave importada. O poder efetivo estava no ponto local de dependência, junto com a responsabilidade de manter um veto verificável.

Quatro registros em vez de uma porcentagem

O registro de geração liga impressão digital a data, pacote, biblioteca, aplicação, arquitetura, algoritmo e tamanho. O registro de distribuição mapeia cópias privadas, certificados, servidores, authorized_keys, known_hosts, pares, imagens, backups e parceiros.

O registro de substituição conecta impressão antiga e nova, canal de autenticação, responsável e prazo. O registro de rejeição prova que a chave antiga falha, que o certificado velho é recusado pelos clientes testados e que qualquer exceção possui dono e vencimento.

Percentual de patch mede o início. Resíduo de autoridade mede o fim.

Limites da evidência

As fontes oficiais não fornecem o total de chaves fracas ou de explorações. Os 98.301 fluxos formam um modelo limitado. Unknown não prova segurança nem vulnerabilidade. Datas de arquivo podem mudar em backup ou por relógio incorreto. GnuPG e GnuTLS usavam outras fontes. A regeneração de chaves de host dependia do pacote e da escolha administrativa. Reemitir um certificado não demonstra que todos os clientes consultaram a revogação.

O resultado sustentado é mais preciso: o gerador corrigido protegeu o futuro; as credenciais antigas mantiveram poder até que cada dependente as encontrasse e recusasse.

Fontes