Kees Cook, ex-administrador do sistema principal do kernel.org e líder da Equipe de Segurança do Ubuntu, demonstrou a possibilidade de criar um commit cujo identificador curto coincide com um commit já adicionado ao núcleo do Linux. O experimento foi realizado como uma confirmação da viabilidade da transição para identificadores curtos de 16 caracteres em commits no núcleo do Linux, assunto anteriormente discutido na lista de discussão dos desenvolvedores do núcleo, mas não aprovado por Linus Torvalds.
Os identificadores curtos de commits são formados ao deixar os primeiros 12 caracteres do hash SHA-1 (48 bits de um total de 160 bits). Como o número de objetos no núcleo identificados através do hash SHA-1 ultrapassou 13 milhões, a ocorrência de colisões ao usar um prefixo de 12 caracteres se tornou uma questão de tempo. Como exemplo, foram mostrados objetos já adicionados ao núcleo que se cruzam em seus identificadores de 11 caracteres. Além disso, foi mencionado que a sobreposição de identificadores de 12 caracteres já foi registrada em outubro, mas antes do envio do patch, foi detectada pela ferramenta checkpatch.
Os identificadores curtos são usados na publicação de links curtos para commits, assim como são indicados ao enviar mudanças na tag ‘Fixes’, como referência a um commit cuja falha foi corrigida no patch enviado (por exemplo, ‘Fixes: e21d2170f366’). A ocorrência de colisões, onde várias mudanças diferentes estão associadas a um único identificador curto, pode resultar na interrupção de ferramentas de análise e verificação de mudanças que consideram o conteúdo das tags ‘Fixes’. Por exemplo, essas tags são consideradas no manipulador check_fixes, usado na branch linux-next, bem como em scripts de análise de correções de vulnerabilidades e rastreamento do ciclo de vida de patches.
Linus Torvalds foi cético em relação à proposta de aumentar o tamanho mínimo dos identificadores curtos, uma vez que, na verdade, o número de commits no repositório é significativamente menor do que o número de objetos (cerca de 1/8). Provavelmente, se houver interseções aleatórias, elas ocorrerão entre um commit e um objeto de outro tipo (como um blob ou um branch). Na sua opinião, os identificadores curtos devem ser visualmente claros, legíveis e facilmente citáveis, e atualmente não há justificativas objetivas para aumentar seu tamanho.
Um dos desenvolvedores sugeriu reduzir o tamanho aumentando o número de bits significativos, utilizando um novo formato baseado na codificação Base36 (caracteres 0-9a-z) em vez de dígitos hexadecimais. Na opinião de Linus, essa alteração criaria mais problemas do que resolveria. Por exemplo, seria necessário adicionar suporte ao novo formato nas utilidades existentes e introduzir um identificador de formato para diferenciar o formato antigo do novo.
Para demonstrar que o problema com identificadores curtos não é hipotético e que sua resolução não deve ser adiada, Kees Cook elaborou uma mudança na documentação do núcleo, cujo identificador curto (1da177e4c3f4) coincidiu com o identificador do commit que criou o branch do núcleo 2.6.12-rc2. A colisão foi encontrada após 6 horas de cálculos em um sistema com GPU NVIDIA GeForce RTX 3080.
A busca foi realizada usando a ferramenta lucky-commit — espaços em branco aleatórios eram adicionados ao texto do patch até que o prefixo SHA-1 de 12 caracteres coincidisse com os prefixos de commits já existentes no núcleo. Na opinião de Kees, o problema não é tanto as interseções aleatórias, mas a possibilidade de manipulação dos identificadores curtos para fins maliciosos, como burlar verificações.
Fonte: opennet.ru
