A história de como tropecei na vulnerabilidade das chaves fracas do Debian

A história de como acabei esbarrando na vulnerabilidade das chaves fracas do Debian

• Em março de 2008, o autor estava trabalhando na Engine Yard (EY)
• Na época, a EY ajudava o GitHub oferecendo infraestrutura gratuita
• À medida que o GitHub crescia, surgiu um problema de lentidão no tempo de login via SSH
• O GitHub gerenciava chaves SSH usando o arquivo padrão ~/.ssh/authorized_keys
• Quando um usuário se conecta, o SSH abre esse arquivo e faz uma busca linear por uma chave que corresponda à apresentada pelo usuário
• Normalmente isso não é um problema porque há só algumas chaves, mas, quando o número de usuários cresce como no GitHub, isso fica lento

Decisão de usar um banco de dados MySQL em vez do arquivo authorized_keys

• Depois de avaliar várias alternativas, decidiram aplicar um patch no OpenSSH para que a busca de chaves fosse feita em um banco de dados MySQL
• Foi uma decisão tomada com cautela, e houve muito esforço para não comprometer a segurança
• A mudança foi aplicada no começo de abril de 2008 e resolveu o problema de velocidade no login via SSH

Algo estranho aconteceu

• Um mês depois, no começo de maio, surgiu um problema em que alguns usuários conseguiam acessar via SSH os repositórios de outros usuários
• A investigação mostrou que usuários diferentes estavam usando chaves com a mesma impressão digital
• Isso não deveria acontecer, a menos que estivessem compartilhando a mesma chave
• Os usuários disseram que não se conheciam e não sabiam como suas chaves poderiam ter vazado
• O mesmo problema foi encontrado em outros pares de usuários
• O único ponto em comum era que todos usavam sistemas Debian ou Ubuntu

Identificando a causa

• Em 13 de maio de 2008, a divulgação do DSA-1571-1 deixou tudo claro
• Um mantenedor do Debian, ao limpar o código de geração de números aleatórios do OpenSSL, reduziu por engano o número de chaves possíveis para cerca de 32.000
• Muitas pessoas se cadastraram no GitHub e, seguindo as boas práticas, geraram novas chaves, o que levou às colisões
• Depois disso, o autor acabou se envolvendo ainda mais com esse problema, inclusive usando chaves fracas já conhecidas para encontrar autoridades certificadoras afetadas

Opinião do GN⁺

• Para descobrir uma vulnerabilidade tão importante assim, é preciso ter tempo e energia para pensar “isso está estranho” e investigar com persistência. Normalmente não temos essa folga, então é preciso contar com sorte.
• A maioria das pessoas está tão ocupada no dia a dia que é difícil ir até a causa raiz de um problema. Recuperar esse espaço no nosso setor é uma tarefa importante.
• O OpenSSL é uma das bibliotecas de criptografia mais usadas no mundo, então o impacto de uma vulnerabilidade dessas é enorme. Isso mostra bem os pontos fortes e fracos do open source.
• Para prevenir vulnerabilidades assim, é preciso reforçar revisão de código e auditorias de segurança, e analisar com ainda mais cuidado mudanças em partes críticas. Mesmo assim, não existe método perfeito.
• Ainda assim, o open source tem a vantagem de permitir que especialistas examinem diretamente o código e encontrem problemas. Em programas fechados, isso nem sequer é possível.

[GN⁺]

Comentários do Hacker News

• Luciano Bello descobriu a vulnerabilidade CVE-2008-0166 por acaso e, de acordo com os logs de IRC da época, eram necessários muitos números primos e nem sempre se obtinha o mesmo número
• Parece que o setor como um todo teve sorte, porque havia alguém com a habilidade, o tempo e a energia para fazer uma grande diferença no momento certo. Este é um caso em que as estatísticas de “muitos olhos” e “a luz do sol é o melhor desinfetante” parecem bem reais. Por menor que seja a probabilidade de alguém encontrar um bug por acaso, as pessoas acabam encontrando porque isso pode acontecer. Já em código proprietário/fechado, essa probabilidade é 0
• A mudança que causou essa vulnerabilidade não foi feita às pressas. Um mantenedor levantou o problema na mailing list do OpenSSL, pediu feedback e propôs uma solução, recebendo algum retorno, inclusive do upstream. O resultado foi uma vulnerabilidade terrível, mas parece ter sido um caso extremamente infeliz em que ninguém percebeu o problema
• O GitHub concluiu que a melhor opção era aplicar um patch no OpenSSH para consultar chaves indexadas por impressão digital em um banco de dados MySQL. Parece ter sido escolhido em vez de SQLite porque era o tipo de situação em que o MySQL podia brilhar, dado o contexto de tentar acelerar o acesso a ~/.ssh/authorized_keys
• Isso leva a pensar na possibilidade de algo assim acontecer na função de geração de seed de uma carteira física de Bitcoin popular, e nas consequências disso
• O episódio de detectar chaves RSA com fatores comuns p ou q usando GCD também foi interessante
• Dá para ver que um tempo de login SSH lento é uma pista que vale a pena investigar por vários motivos
• O RNG do OpenSSL era semeado com memória de pilha não inicializada e com o PID, e parece que, mesmo sem o patch do Debian, semear apenas com o PID já era algo bastante arriscado
• Fico me perguntando se o GitHub ainda roda esse OpenSSH com patch
• A frase dizendo que Ezra Zygmuntowicz apresentou o GitHub ao autor e lhe deu tempo para investigar o problema com a equipe do GitHub é engraçada, talvez porque soe como se houvesse um grande problema dentro da própria equipe do GitHub
• Fico pensando por quanto mais tempo isso teria passado despercebido se Luciano não tivesse encontrado. Acho que só alguns poucos lugares, como o GitHub ou grandes provedores de nuvem que armazenam milhares de chaves de usuários, teriam tropeçado nisso por acaso