Git Hash Chain Malleability

Resumo Técnico: Maleabilidade da Cadeia de Hashes Git

Declaração do Problema
O artigo contesta o invariante amplamente aceito nos ecossistemas Git de que um hash de commit identifica de forma única e imutável um conteúdo assinado específico. Embora a documentação do Git afirme que hashes criptograficamente seguros permitem que terceiros confiem no hash como um endereço para o objeto assinado e suas referências, este artigo demonstra que essa suposição falha para commits assinados. Especificamente, um atacante sem acesso à chave privada de assinatura, e sem quebrar a função de hash subjacente (SHA-1 ou SHA-256), pode gerar um objeto de commit distinto com o mesmo tree, metadados e mensagem, mas um hash de commit diferente. Crucialmente, este commit modificado retém uma assinatura válida e recebe um selo "Verified" (Verificado) de forges de Git como o GitHub. Isso ocorre porque o hash do commit é uma função determinística do conteúdo serializado (incluindo os bytes da assinatura); alterar os bytes da assinatura altera o hash. Este fenômeno, denominado "maleabilidade da cadeia de hash", permite que um atacante crie um commit "fantasma" que é funcionalmente idêntico ao original, mas possui um identificador diferente, cascateando mudanças para todos os hashes de commit dependentes na cadeia.

Metodologia
O autor identifica que a lacuna entre "uma assinatura válida" e "esta codificação de assinatura específica" permite a maleação. Eles categorizam três técnicas distintas para explorar essa lacuna, cada uma visando uma camada diferente da representação da assinatura dentro do objeto de commit do Git:

1. Maleação Matemática (ECDSA): Explorando a simetria algébrica das assinaturas ECDSA. Para uma assinatura $(r, s)$ em uma curva de ordem $n$, o par $(r, n-s)$ também é uma assinatura válida para a mesma mensagem. O autor modifica o valor $s$ no pacote OpenPGP, recodifica o inteiro e atualiza os cabeçalhos de comprimento do pacote. Isso preserva a validade da assinatura enquanto altera a sequência de bytes.
2. Maleação Estrutural (RSA e EdDSA): Visando a estrutura do contêiner OpenPGP em vez do valor da assinatura propriamente dito. O autor anexa um subpacote bem formado e não crítico (tipo 100, privado/experimental) à região não hashada do pacote de assinatura. De acordo com a RFC 4880, a região não hashada não é coberta pela assinatura criptográfica. Ao adicionar dados aqui e ajustar o comprimento do pacote, a assinatura permanece válida, mas a representação de bytes do objeto de commit muda.
3. Maleação de Codificação (S/MIME): Explorando a diferença entre DER (Distinguished Encoding Rules) e BER (Basic Encoding Rules) em ASN.1. Assinaturas S/MIME são estruturas CMS que exigem codificação DER canônica. O autor reescreve um campo de comprimento dentro do envelope CMS de sua forma curta canônica para uma forma longa equivalente (por exemplo, codificando o comprimento 32 como 0x81 0x20 em vez de 0x20). Embora isso viole as regras estritas de DER, permanece como um BER válido. O valor da assinatura e o conteúdo assinado permanecem intactos, preservando a verificação.

Principais Contribuições

• Caracterização de Técnicas: O artigo define e demonstra três rotas de maleação (matemática, estrutural e de codificação) que cobrem todos os esquemas de assinatura suportados pela verificação GPG do GitHub (ECDSA, RSA, EdDSA e S/MIME/CMS).
• Validação no Lado do Servidor: O autor mostra que estes não são meramente peculiaridades de parser locais. O verificador do lado do servidor do GitHub aceita as três técnicas de maleação. Consequentemente, a forge emite registros "Verified" independentes e persistentes para ambos os commits originais e maleados, indexados por seus hashes distintos.
• Análise de Impacto: O artigo analisa as consequências para sistemas que dependem de hashes de commit como chaves primárias endereçáveis por conteúdo, incluindo:
  • Bloqueio Baseado em Hash: Ferramentas de resposta a incidentes que bloqueiam hashes de commits específicos podem ser contornadas ao realizar o push do commit maleado "fantasma", que possui um hash diferente, mas conteúdo idêntico.
  • Pinagem de Dependências: Embora a pinagem de SHA completo (ex: em módulos Go ou Nixpkgs) mantenha a integridade contra substituição de conteúdo, a maleabilidade cria um aliasing no nível do conteúdo assinado. Lockfiles regenerados a partir de espelhos podem registrar o hash "fantasma", levando a entradas de cache duplicadas ou registros de proveniência inconsistentes.
  • Builds Reproduzíveis: Sistemas que tratam o hash do commit como o identificador de revisão imutável (ex: SLSA Source Track, Sigstore Gitsign) são enfraquecidos. Um único conteúdo pode gerar múltiplos âncoras de confiança em logs de transparência, duplicando em vez de defender a âncora de confiança.
• Ferramental de Prova de Conceito: O autor fornece ferramentas de código aberto (interactive-malleator.py e setup-ghost.py) que automatizam essas técnicas, reescrevem cadeias de commits descendentes para manter a consistência do grafo e verificam os resultados contra forges locais e remotas.

Resultos

• Verificação Local: Todas as três técnicas passam na verificação local usando git verify-commit para esquemas baseados em OpenPGP (ECDSA, RSA, EdDSA). Para S/MIME, parsers locais estritos (como o gpgsm usando libksba) rejeitam a codificação DER não canônica, mas o parser mais permissivo do GitHub a aceita.
• Aceitação pelo GitHub: O GitHub aceita todos os três métodos de maleação. A plataforma não canonicaliza os contêineres de assinatura antes da verificação. Como resultado, um único commit lógico pode ser representado por uma família ilimitada de hashes distintos em bytes, cada um marcado como "Verified" e apresentado como histórico não relacionado em visualizações de comparação (ex: "1 commit ahead and 1 commit behind").
• Persistência: O status "Verified" é durável. Mesmo se a chave de assinatura for rotacionada ou revogada, os commits maleados mantêm seus registros de verificação independentes porque a forge indexa o registro ao hash do commit específico, não ao conteúdo ou estado da chave.

Significância
O artigo conclui que a suposição de que um hash de commit assinado e verificado é um handle único para um conteúdo específico é falsa. O ataque não depende de colisões de hash ou falsificação de conteúdo, mas sim da maleabilidade da própria codificação da assinatura. A significância prática é que sistemas que dependem de hashes de commit para bloqueio, pinagem de dependências e verificação de builds reproduzíveis são vulneráveis à equivocação. O autor argumenta que a confiança não deve ser depositada no hash bruto de um objeto assinado cuja codificação é controlada por um adversário; em vez disso, os sistemas devem canonicalizar e verificar o conteúdo antes de tratar o hash como um identificador único. O artigo observa que, até a data de escrita, o problema permanece sem solução no Git ou nas principais forges de Git.